Computing systems, networks, and notifications

ABSTRACT

Systems and methods electronically produce a local estimate of less-than-critical resources based on a client-side version of digital rules and coarse values received from an online service provider. Although using the client-side version of digital rules and the coarse values may not include all the parameters and values needed to provide a fully accurate estimate of the resource, the ability to locally estimate resources without having to make network calls to the online service provider, such as when there are unfavorable conditions or latency of the network, imminent overloading of the online service provider or other operating conditions or demands on the online service provider preventing it from producing a timely more accurate estimate, provides a faster and more efficient way of obtaining a potentially useful estimate of resources.

CROSS-REFERENCE TO RELATED PATENT APPLICATIONS

This application is a continuation-in-part, under 35 C.F.R. 1.53(b)(2)and 1.78(d)(2), that claims priority to, and the benefit of, U.S. patentapplication Ser. No. 16/585,829 filed on Sep. 27, 2019, and is also acontinuation-in-part that claims priority to, and the benefit of, U.S.patent application Ser. No. 17/127,205 filed on Dec. 18, 2020, thelatter of which (application Ser. No. 17/127,205) further claimspriority to provisional application No. 62/950,284, filed Dec. 19, 2019.The entireties of each of these earlier applications are incorporatedherein by reference.

BRIEF SUMMARY

The present description gives instances of computer systems, devices andstorage media that may store programs and methods. Embodiments of thesystem may produce a local estimate of less-than-critical resourcesbased on a client-side version of digital rules and coarse valuesreceived from an online service provider. Although using the client-sideversion of digital rules and the coarse values may not include all theparameters and values needed to provide a fully accurate estimate of theresource, the ability to locally estimate resources without having tomake network calls to the online service provider provides a faster andmore efficient way of obtaining a potentially useful estimate ofresources. For example, this functionality to locally estimate resourcesmay provide a faster and more efficient way of obtaining a potentiallyuseful estimate of resources when there are unfavorable conditions orlatency of the network, imminent overloading of the online serviceprovider or other operating conditions or demands on the online serviceprovider preventing it from producing a timely more accurate estimate.

In addition, providing the coarse values instead of a set of values thatincludes all the parameters and values needed to provide a fullyaccurate estimate of the resource reduces the data package size thatneeds to be distributed to clients, thus making it more efficiently andeasily deployable to the client computer systems. In variousembodiments, the system may also provide the client with a selectableoption to produce the local estimate without having to make one or morenetwork calls to the online service provider and/or produce the moreaccurate estimate via one or more immediate or follow-up network callsto the online service provider. This reduces internet traffic and it canbe critical when the internet is down or slow, and the results of thecomputations are needed in real time. Also, producing the more accurateestimate may be made via one or more follow-up network calls to theonline service provider after producing the local estimate when networkand operating conditions of the online service provider are morefavorable for doing so. Using the more accurate estimates, the systemmay then perform reconciliation with local estimates to finddiscrepancies between the local estimates and the more accurateestimates for the system to learn from such discrepancies andautomatically implement improvements in how the local estimates arecomputed.

Therefore, the systems and methods described herein for using coarsevalues for estimating less-than-critical resources improve thefunctioning of computer or other hardware, such as by reducing theprocessing, storage, and/or data transmission resources needed toperform various tasks, thereby enabling the tasks to be performed byless capable, capacious, and/or expensive hardware devices, enabling thetasks to be performed with less latency and/or preserving more of theconserved resources for use in performing other tasks or additionalinstances of the same task.

In further embodiments, this application also discloses the following.When businesses make, sell, or buy goods, they are required by law tocompute the amounts of money they must remit as taxes to various taxjurisdictions, and then remit these amounts to the tax jurisdictions. Ifthey fail to accurately report and remit taxes, they may be subject toaudits and fines—and ignorance of the law is not an excuse.

Businesses generally collect information relating to their operations,such as by using enterprise resource planning (“ERP”) softwareapplications and accounting applications. ERP applications manageinformation relating to a business's activities, such as sales, resourcemanagement, production, inventory management, delivery, billing, and soon. Accounting applications manage a business's accounting information,such as purchase orders, sales invoices, payroll, accounts payable,accounts receivable, and so on. ERP applications, accountingapplications, ecommerce applications and other conventionally usedapplications fail to provide accurate, reliable per-jurisdiction taxcompliance information in a timely and efficient manner according to thevarious different rules in various different tax jurisdictions.

To solve the above technical problems, disclosed herein is methodcomprising: updating, by a computer system, stored rules for a certainone of a plurality of tax jurisdictions, the stored rules being aboutestablishing nexus for purposes of remitting transaction tax in thecertain tax jurisdiction; comparing, by the computer system, storedinformation about goods or services sold by an entity in the certain taxjurisdiction against the updated stored rules for the certain taxjurisdiction; generating, by the computer system, information regardingpotential lack of tax compliance of the entity for the certain taxjurisdiction based on the comparison; and transmitting, by the computersystem over a network, to a client computing device associated with theentity, a notification about the generation of the information.

Also, disclosed herein is a system comprising at least one processor anda memory coupled to the at least one processor. The memory storesinstructions that, when executed by the at least one processor, causethe system to perform operations comprising: updating, by a computersystem, stored rules for a certain one of a plurality of taxjurisdictions, the stored rules being about establishing nexus forpurposes of remitting transaction tax in the certain tax jurisdiction;comparing, by the computer system, stored information about goods orservices sold by an entity in the certain tax jurisdiction against theupdated stored rules for the certain tax jurisdiction; generating, bythe computer system, information regarding potential lack of taxcompliance of the entity for the certain tax jurisdiction based on thecomparison; and transmitting, by the computer system, to a clientcomputing device associated with the entity over a network anotification about the generation of the information.

Also disclosed herein is a non-transitory computer-readable storagemedium having computer-executable instructions stored thereon that, whenexecuted by at least one processor, cause the at least one processor toperform operations comprising: updating, by a computer system, storedrules for a certain one of a plurality of tax jurisdictions, the storedrules being about establishing nexus for purposes of remittingtransaction tax in the certain tax jurisdiction; comparing, by thecomputer system, stored information about goods or services sold by anentity in the certain tax jurisdiction against the updated stored rulesfor the certain tax jurisdiction; generating, by the computer system,information regarding potential lack of tax compliance of the entity forthe certain tax jurisdiction based on the comparison; and transmitting,by the computer system, to a client computing device associated with theentity over a network a notification about the generation of theinformation.

Also disclosed herein is a method comprising: electronically accessing,by a computer system, information about goods or services sold by aplurality of entities; determining, by the computer system, for eachentity of the plurality of entities, whether there exists a potentiallack of transaction tax compliance of the entity in each taxjurisdiction of a plurality of tax jurisdictions based on the accessedinformation; and for each entity of the plurality of entities for whichit is determined by the computer system there exists potential lack oftax compliance in one or more of the plurality of tax jurisdictions,electronically notifying the entity regarding the potential lack of taxcompliance.

Also disclosed herein is another system comprising at least oneprocessor and a memory coupled to the at least one processor. The memorystores instructions that, when executed by the at least one processor,cause the system to perform operations comprising: electronicallyaccessing information about goods or services sold by a plurality ofentities; determining for each entity of the plurality of entities,whether there exists a potential lack of transaction tax compliance ofthe entity in each tax jurisdiction of a plurality of tax jurisdictionsbased on the accessed information; and for each entity of the pluralityof entities for which it is determined by a computer system there existspotential lack of tax compliance in one or more of the plurality of taxjurisdictions, electronically notifying the entity regarding thepotential lack of tax compliance.

Also disclosed herein is a non-transitory computer-readable storagemedium having computer-executable instructions stored thereon that, whenexecuted by at least one processor, cause a system to perform operationscomprising: electronically accessing information about goods or servicessold by a plurality of entities; determining, for each entity of theplurality of entities, whether there exists a potential lack oftransaction tax compliance of the entity in each tax jurisdiction of aplurality of tax jurisdictions based on the accessed information; andfor each entity of the plurality of entities for which it is determinedby a computer system there exists potential lack of tax compliance inone or more of the plurality of tax jurisdictions, electronicallynotifying the entity regarding the potential lack of tax compliance.

As shown above and in more detail throughout the present disclosure, thepresent disclosure provides technical improvements in computer networksto existing computerized systems to facilitate estimation of resources.

These and other features and advantages of the claimed invention willbecome more readily apparent in view of the embodiments described andillustrated in this specification, namely in this written specificationand the associated drawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The components in the drawings are not necessarily drawn to scalerelative to each other. Like reference numerals designate correspondingparts throughout the several views.

FIG. 1 is a diagram showing sample aspects of embodiments of the presentdisclosure involving a client receiving a software development kit (SDK)including client-side versions of digital rules (CSVDR) that is animprovement in automated computerized systems.

FIG. 2 is a diagram showing sample aspects of embodiments of the presentdisclosure involving producing and outputting a local estimate of aresource for a dataset by the CSVDR and values of a coarse values file(CVF) received by the client of FIG. 1 , which is an improvement inautomated computerized systems.

FIG. 3 is a diagram showing sample aspects of embodiments of the presentdisclosure involving producing, via one or more computer network callsto an online service platform (OSP) system, a more accurate estimate(MAE) of the resource that is more accurate than the local estimate ofFIG. 2 based on the dataset and digital rules stored remotely at the OSPsystem that is an improvement in automated computerized systems.

FIG. 4 is a diagram showing sample aspects of embodiments of the presentdisclosure involving the client of FIG. 3 transmitting the localestimate to the OSP for reconciliation with the more accurate estimateto find discrepancies between the local estimate and the more accurateestimate that is an improvement in automated computerized systems.

FIG. 5 is a diagram showing sample aspects of embodiments of the presentdisclosure involving the client of FIG. 2 receiving, from the OSP acrossthe network, updates for producing the local estimate, which is animprovement in automated computerized systems.

FIG. 6 is a flowchart for illustrating a sample method for producing alocal estimate of a resource that is an improvement in automatedcomputerized systems, according to embodiments of the presentdisclosure.

FIG. 7 is a flowchart illustrating a sample method for producing a localestimate of a resource based on an updated CVF that is an improvement inautomated computerized systems, according to embodiments of the presentdisclosure.

FIG. 8 is a flowchart illustrating a sample method for computingdifferences between local estimates and more accurate estimates that isan improvement in automated computerized systems, according toembodiments of the present disclosure.

FIG. 9 is a sample view of a User Interface (UI) of a system forestimating less-than-critical resources that provides a selectableoption to produce a local estimate of a resource based on a selection ofa degree of risk between a lower risk local estimate and a higher risklocal estimate that is an improvement in automated computerized systems,according to embodiments of the present disclosure.

FIG. 10 is a sample view of a UI of a system for estimatingless-than-critical resources that provides a selectable option toreceive both local estimates and more accurate estimates via follow-upcomputer network calls to an OSP system that is an improvement inautomated computerized systems, according to embodiments of the presentdisclosure.

FIG. 11 is another sample view of the UI of FIG. 10 providing aselectable option to indicate when the follow-up computer network callsto the OSP system should be attempted that is an improvement inautomated computerized systems, according to embodiments of the presentdisclosure.

FIG. 12 is another sample view of a UI of a system for estimatingless-than-critical resources that provides selectable options toindicate under what conditions particular sources of resource estimateproduction are to be automatically used, which is an improvement inautomated computerized systems, according to embodiments of the presentdisclosure.

FIG. 13 is a diagram showing a representation of an example dataset in asystem for estimating less-than-critical resources and indicating forwhich relationship instances of the dataset a local estimate wasproduced and also indicating for which relationship instances of thedataset a more accurate estimate was produced, which is an improvementin automated computerized systems, according to embodiments of thepresent disclosure.

FIG. 14 is another sample view of a UI of a system for estimatingless-than-critical resources that provides a selectable option toindicate whether a local estimate of resources is always to be producedand whether to enable local learning functions of the system thatcompares the local estimate with results of more accurate estimates viaAPI calls when available, which is an improvement in automatedcomputerized systems, according to embodiments of the presentdisclosure.

FIG. 15 is a diagram showing a representation of an example dataset in asystem for estimating less-than-critical resources and discrepanciesbetween local estimates and more accurate estimates that were producedfor relationship instances of the dataset, which is an improvement inautomated computerized systems, according to embodiments of the presentdisclosure.

FIG. 16 is another sample view of a UI of a system for estimatingless-than-critical resources that provides a selectable option toindicate how local estimates will be determined by the system, which isan improvement in automated computerized systems, according toembodiments of the present disclosure.

FIG. 17 is a diagram showing a representation of an example dataset in asystem for estimating less-than-critical resources and discrepanciesbetween local estimates and more accurate estimates resulting fromfollow-up API calls to the OSP system that were produced for variousrelationship instances of the dataset, which is an improvement inautomated computerized systems, according to embodiments of the presentdisclosure.

FIG. 18 is a diagram showing sample aspects of embodiments of a systemfor estimating less-than-critical resources in a use case of anembodiment that is an improvement in automated computerized systems,according to embodiments of the present disclosure.

FIG. 19 is a diagram showing example of parameters and associatedparameter values that may be included in a CVF of a system forestimating less-than-critical resources that is an improvement inautomated computerized systems, according to embodiments of the presentdisclosure.

FIG. 20 is a diagram showing another example of parameters andassociated parameter values that may be included in a CVF of a systemfor estimating less-than-critical resources that is an improvement inautomated computerized systems, according to embodiments of the presentdisclosure.

FIG. 21 is a block diagram showing an example configuration of a system,according to various embodiments of the present disclosure.

FIG. 22 is a block diagram showing more details of a computer of anexample customer entity of FIG. 1 , with reference to the communicationnetwork and the software service platform, according to variousembodiments of the present disclosure.

FIG. 23 is a block diagram showing an example software architectureworking with a tax compliance information generation engine, accordingto various embodiments of the present disclosure.

FIG. 24 is a flow diagram of an example process and corresponding dataflow for transmitting notifications about information regardingpotential lack of tax compliance, according to various embodiments ofthe present disclosure.

FIG. 25 is a block diagram showing more details of a tax complianceinformation generation engine of FIG. 3 , according to variousembodiments of the present disclosure.

FIG. 26 depicts an example user interface showing example notificationsabout information regarding potential lack of tax compliance, accordingto various embodiments of the present disclosure.

FIG. 27 is a flow diagram of an example process for generatinginformation regarding potential lack of tax compliance of an entity andtransmitting a corresponding notification, according to variousembodiments of the present disclosure.

FIG. 28 is a flow diagram of an example process useful in generatinginformation regarding potential lack of tax compliance, according tovarious embodiments of the present disclosure.

FIG. 29 is a flow diagram of an example process useful in determiningfor an entity whether there is a potential lack of tax compliance in atax jurisdiction based on aggregated transactions, according to variousembodiments of the present disclosure.

FIG. 30 is a flow diagram of an example process for notifying aplurality of entities whether there is a potential lack of taxcompliance in a plurality of jurisdictions, according to variousembodiments of the present disclosure.

FIG. 31 is a flow diagram of another example process for notifying aplurality of entities whether there is a potential lack of taxcompliance, according to various embodiments of the present disclosure.

DETAILED DESCRIPTION

The description that follows includes systems, methods, techniques,instruction sequences, and computing machine program products thatembody illustrative embodiments of the disclosure. In the followingdescription, for the purposes of explanation, numerous specific detailsare set forth in order to provide an understanding of variousembodiments of the inventive subject matter. It will be evident,however, that embodiments of the inventive subject matter may bepracticed without these specific details. In general, well-knownstructures and methods associated with underlying technology have notbeen shown or described in detail to avoid unnecessarily obscuringdescriptions of the preferred embodiments.

FIG. 1 is a diagram showing sample aspects of embodiments of the presentdisclosure involving a client 193 receiving a software development kit(SDK) 125 including client-side versions of digital rules (CSVDR) 170A,which is an improvement in automated computerized systems.

A sample computer system 195 according to embodiments is shown. Thecomputer system 195 has one or more processors 194 and a memory 130. Thememory 130 stores programs 131 and data 138. The one or more processors194 and the memory 130 of the computer system 195 thus implement aservice engine 183. One or more of the components of the computer system195 may also be present in client computer system 190 of client 193 forperforming the operations and implementing the functionality of computersystem 190 described herein.

The computer system 195 can be located in “the cloud.” In fact, thecomputer system 195 may optionally be implemented as part of an onlinesoftware platform (OSP) 198. The OSP 198 can be configured to performone or more predefined services, for example, via operations of theservice engine 183. Such services can be, but are not limited to:generation and delivery of a software development kit (SDK) 125 for theclient 193 to perform local estimates of resources, generation anddelivery of a coarse values file (CVF) for the client 193 to performlocal estimates of resources, searches, determinations, computations,verifications, notifications, the transmission of specializedinformation (including digital rules for estimating resources and datathat effectuates payments, or remits resources), performing moreaccurate estimations of resources, determining discrepancies betweenresources estimated by client computer system 190 and the more accurateestimation of resources performed by the OSP 198, the generation andtransmission of documents, the online accessing of other systems todetermine digital rules, and so on, including what is described in thisdocument. Such services can be provided as a Software as a Service(SaaS). The SDK 125 may be a collection of software development tools inone package installable by the client computer system 190. The SDK 125may facilitate the creation of applications, such as the CCF 126 byhaving a compiler, debugger and a software framework. The SDK 125 mayinclude libraries, documentation, code samples, processes, and guidesthat the client 193 can use and integrate with the connector 122 andother applications of the computer system 190 to facilitate the computersystem 190 performing local estimates of resources.

A user 192 may be standalone. The user 192 may use a computer system 190that has a screen 191, on which user interfaces (UIs) may be shown. Inembodiments, the user 192 and the computer system 190 are consideredpart of a client 193, which can be referred to also merely as entity. Insuch instances, the user 192 can be an agent of the client 193, and evenwithin a physical site of the client 193, although that is notnecessary. In embodiments, the computer system 190 or other device ofthe user 192 or the client 193 are client devices for the computersystem 195.

The computer system 190 may access the computer system 195 via acommunication network 188, such as the internet. In particular, theentities and associated systems of FIG. 1 may communicate via physicaland logical channels of the communication network 188. For example,information may be communicated as data using the Internet Protocol (IP)suite over a packet-switched network such as the Internet or otherpacket-switched network, which may be included as part of thecommunication network 188. The communication network 188 may includemany different types of computer networks and communication mediaincluding those utilized by various different physical and logicalchannels of communication, now known or later developed. Non-limitingmedia and communication channel examples include one or more, or anyoperable combination of: fiber optic systems, satellite systems, cablesystems, microwave systems, asynchronous transfer mode (“ATM”) systems,frame relay systems, digital subscriber line (“DSL”) systems, cableand/or satellite systems, radio frequency (“RF”) systems, telephonesystems, cellular systems, other wireless systems, and the Internet. Invarious embodiments the communication network 188 can be or include anytype of network, such as a local area network (LAN), a metropolitan areanetwork (MAN), a wide area network (WAN), or the internet.

Downloading or uploading may be permitted from one of these two computersystems to the other, and so on. Such accessing can be performed, forinstance, with manually uploading files, like spreadsheet files, etc.Such accessing can also be performed automatically. The computer system190 and the computer system 195 may exchange requests and responses witheach other. Such can be implemented with a number of architectures.

In one such architecture, a device remote to the service engine 183,such as computer system 190, may have a certain application, such as aclient computing facility (CCF) 126 and an associated connector 122 thatis integrated with, sits on top of, or otherwise works with that certainapplication. The connector 122 may be able to fetch from a remotedevice, such as the computer system 195, the details required for theservice desired from the OSP 198. The computer system 190 may receive,via network 188, an SDK 125 from the OSP 198 that includes the CCF 126and/or the connector 122. The OSP 198 may prepare and send the CCF 126as part of the SDK 125 automatically or in response to a request fromthe client computer system 190. In requesting services from the OSP 198,the client computer system 190 may form an object or payload, and thensend or push a request that carries the payload to the service engine183 via a service call. The service engine 183 may receive the requestwith the payload. The service engine 183 may then apply digital rules tothe payload to determine a requested resource, including producing anestimate of a resource, form a payload that is an aspect of the resource(e.g., that includes the estimate) and then push, send, or otherwisecause to be transmitted a response that carries the payload to theconnector 122. The connector reads the response, and forwards thepayload to the certain application, such as the CCF 126.

In some embodiments, the computer system 195 may implement a REST(Representational State Transfer) API (Application ProgrammingInterface) (not shown). REST or RESTful API design is designed to takeadvantage of existing protocols. While REST can be used over nearly anyprotocol, it usually takes advantage of HTTP (Hyper Text TransferProtocol) when used for Web APIs. In some embodiments, this architectureenables the client 193 to directly consume a REST API from theirparticular application (e.g., CCF 126), without using a connector 122.The particular application of the remote device may be able to fetchinternally from the remote device the details required for the servicedesired from the OSP 198, and thus send or push the request to the RESTAPI. In turn, the REST API talks in background to the service engine183. Again, the service engine 183 determines the requested resource(which may be an estimate if the resource) and sends an aspect of itback to the REST API. In turn, the REST API sends the response that hasthe payload to the particular application (e.g., CCF 126).

As one example service the OSP 198 may provide to the client 193, theservice engine 198 of the OSP may use digital rules to estimateresources for the client 193. However, the CCF 126 includes CSVDR 170Athat may instead, or additionally, be used by the CCF 126 of the clientcomputer system 190 to produce local estimates of the same resources,but with the advantage of not having to make network calls via network188. These CSVDR 170A can be full versions of the digital rules used bythe OSP 198 or less than full versions. For example, the CSVDR 170A ofthe CCF 126 may include local digital rules that can produce resourceestimates in a less refined way than the online digital rules of the OSP198. In many instances, the estimates produced by the OSP 198 using thedigital rules of the OSP 198 may be more accurate than those producedlocally by the CCF 126 of client computer system 190 using the CSVDR170A. In some embodiments, but not always, the CSVDR 170A are a subsetof the online digital rules of the OSP 198.

Moreover, in some embodiments, data from the computer system 190 and/orfrom the computer system 195 may be stored in an Online ProcessingFacility (OPF) 189 that can run software applications, performoperations, and so on. In such embodiments, requests and responses maybe exchanged with the OPF 189, downloading or uploading may involve theOPF 189, and so on. In such embodiments, any devices of the OPF 189 canbe considered to be remote devices, from the perspective of the computersystem 195 and/or client computer system 190.

In some instances, the user 192 or the client 193 may have instances ofrelationships with secondary entities. Only one such secondary entity196 is shown. However, additional secondary entities may be present invarious other embodiments. In this example, the client 193 has arelationship instance 197 with the secondary entity 196. In someembodiments, the secondary entity may also communicate with the client193 via network 188.

In some instances, the user 192, the client 193 and/or one or moreintermediary entities (not shown) may have data about one or moresecondary entities, such as secondary entity 196, for example viarelationship instances of the user 192 or client 193 with the secondaryentity 196. The client 193 and/or the secondary entity 196 may bereferred to as simply entities. One of these entities may have one ormore attributes. Such an attribute of such an entity may be any one ofits name, type of entity, a physical or geographical location such as anaddress, a contact information, an affiliation, a characterization ofanother entity, a characterization by another entity, an association orrelationship with another entity (general or specific instances), anasset of the entity, a declaration by or on behalf of the entity, and soon.

FIG. 2 is a diagram showing sample aspects of embodiments of the presentdisclosure involving producing and outputting a local estimate (LE) 159of a resource for a dataset 135 by using the CSVDR 170A and values of acoarse values file (CVF) 128 received by the client 193 of FIG. 1 ,which is an improvement in automated computerized systems.

A thick line 115 separates this diagram, although not completely orrigorously, into a top portion and a bottom portion. Above the line 115the emphasis is mostly on entities, components, their relationships, andtheir interactions, while below the line 115 emphasis is mostlyprocessing of data that takes place often within one or more of thecomponents above the line 115.

Above the line 115, the sample computer system 195, network 188, clientcomputer system 190 and secondary entity 196 according to embodiments isshown. In embodiments, the computer system 190 generates one or moredatasets. A sample generated dataset 135 is shown below the line 115.The dataset 135 has values that can be numerical, alphanumeric, Boolean,and so on, as needed for what the values characterize. For example, anidentity value ID may indicate an identity of the dataset 135, so as todifferentiate it from other such datasets. At least one of the values ofthe dataset 135 may characterize an attribute of a certain one of theentities 193 and 196. (It should be noted that the arrows 199 describe acorrespondence, but not the journey of data in becoming the dataset135.) For instance, a value D1 may be the name of the certain entity, avalue D2 may be for relevant data of the entity, and so on. Plus, anoptional value B1 may be a numerical base value for an aspect of thedataset, and so on. The aspect of the dataset may be the aspect of thevalue that characterizes the attribute, an aspect of the reason that thedataset was created in the first place, an indication of an identity orother characteristic of the client 193 and/or the secondary entity 196.The dataset 135 may further have additional such values, as indicated bythe horizontal dot-dot-dot to the right of the dataset 135. In someembodiments, the dataset 135 has values that characterize attributes ofeach of the client 193 and the secondary entity 196, but that is notrequired.

The CVF 128 has simple data for use by the CSVDR 170A in producing thelocal LE 159. The data of the CVF 128 might not be necessarily accurate,because it might not cover all the parameters that are needed by all theCSVDR 170A to produce a more accurate estimate. For example, the CVF 128can indicate rates according to particular domains, plus one or morespecial variables. Still, this may not be completely accurate in someinstances as it would only provide approximate estimates because it doesnot discuss or consult other parameters that are needed to produce moreaccurate estimates. In embodiments, the CVF 128 is distributed vianetwork 188 to special subscribers or clients of the OSP 198, which mayinclude client 193. Subscribers, such as client 193, could be ecommerceplatforms, high-volume direct customers of application programminginterface (API) calls for accurate resource computation, accurateresource estimation, etc. In embodiments, the CVF 128 to be distributedis updated by the computer system 198 of the OSP 198 as new and updatedcontent becomes digested. In various, embodiments, the CVF 128 may betransmitted from the OSP 198 via network 188 in response to a requestform the client computer system 190, pushed periodically from the OSP198 to the client computer system 190 and/or as new and updated contentbecomes digested by the OSP 198. The OSP 198 may distribute the CVF 128in a number of ways, including, but not limited to, leveraging afunction of the SDK 125 or calling a CVF subscription API of the serviceengine 183 directly.

In embodiments, stored CSVDR 170A may be included in the CCF 126 andaccessed by the computer system 190. The CSVDR 170A are digital in thatthey are implemented for use by software. For example, the CSVDR 170Amay be implemented within CCF 126. The CCF 126 may access the CSVDR 170Arules 170 and CVF 128 responsive to generating a dataset, such as thedataset 135. The CSVDR 170A may include main rules, which can thus beaccessed by the computer system 190. In this example, three sampledigital main rules are shown explicitly, namely M_RULE5 175A, M_RULE6176A, and M_RULE7 177A. In this example, the CSVDR 170A also includedigital precedence rules P_RULE2 172A and P_RULE3 173A, which can thusbe further accessed by the computer system 190. The CSVDR 170A mayinclude additional rules and types of rules, as suggested by thevertical dot-dot-dots.

In embodiments, a certain one of the digital main rules may beidentified from among the accessed stored CSVDR 170A by the computersystem 190. In particular, values of the dataset 135 can be tested,according to arrows 171A, against logical conditions of the digital mainrules. In this example, the certain main rule M_RULE6 176A is thusidentified, which is indicated also by the beginning of an arrow 178A.Identifying may be performed in a number of ways, and depending on howthe digital main rules are implemented.

A number of examples are possible for how to recognize that a certaincondition of a certain digital rule is met by at least one of the valuesof the dataset 135. For instance, the certain condition could indicate adomain defined by boundary of a region that is within a space. Invarious embodiments, a domain may be a region defined by a boundary asdiscussed above or may be an entity representing or otherwise associatedwith the region. The region could be geometric, and be within a largerspace and may include political boundaries. For example, the regioncould be geographic, within the space of a city, a county, a state, acountry, a continent or the earth. The boundary of the region could bedefined in terms of numbers according to a coordinate system within thespace. In the example of geography, the boundary could be defined interms of groups of longitude and latitude coordinates. In suchembodiments, the certain condition could be met responsive to thecharacterized attribute of the dataset being in the space and within theboundary of the region instead of outside the boundary. For instance,the attribute could be a location of the client 193, and the one or morevalues of the dataset 135 that characterize the location could be one ormore numbers or an address, or longitude and latitude. The condition canbe met depending on how the one or more values compare with theboundary. For example, the comparison may reveal that the location is inthe region instead of outside the region. The comparison can be made byrendering the characterized attribute in units comparable to those ofthe boundary. For example, the characterized attribute could be anaddress that is rendered into longitude and latitude coordinates, and soon. In other instances, instead of rendering the characterized attributein units comparable to those of the boundary, the CCF 126 may insteadconsult a more coarse value in the CVF 128, which maps an aspect of theaddress, such as zip code, to a parameter value associated with the zipcode, such as rate to use in calculating the local estimate.

Where more than one of the digital main rules are found that could beapplied, there are additional possibilities. For instance, the computersystem 190 of FIG. 1 may further access at least one stored digitalprecedence rule, such as P_RULE2 172A or P_RULE3 173A. Accordingly, thecertain digital main rule may be thus identified also from the digitalprecedence rule. In particular, the digital precedence rule may decidewhich one or more of the digital main rules is to be applied. Tocontinue the previous example, if a value of the dataset 135 thatcharacterizes a location, and the location is within multipleoverlapping regions according to multiple rules, the digital precedencerule may decide that all of them are to be applied, or less than all ofthem are to be applied. However, when limited data is available or used,such as when the CCF 126 is using the CVF 128, the digital precedencerule may not be fully applied, such that only one of the digital mainrules may be applied. Equivalent embodiments are also possible, wheredigital precedence rules are applied first to limit an iterative search,so as to test the applicability of fewer than all the rules according toarrows 171A.

In embodiments, an estimated resource may be produced for the dataset135, by the computer system 190 locally applying the certain consequentof the certain digital main rule. The resource can be a computationalresult, a document, an item of value, a representation of an item ofvalue, etc., made, created or prepared for the user 192, the client 193,the secondary entity 196, etc., on the basis of the attribute. As such,in some embodiments, the estimated resource is produced by adetermination and/or a computation. In the example of FIG. 2 , anestimated resource may be produced locally by the CCF 126 for thedataset 135, which is referred to as local estimate (LE) 159. This maybe performed by the CCF 126 of computer system 190 locally applying thecertain M_RULE6 176A, as indicated by the arrow 178A.

The local estimate may be produced in a number of ways. For example, thecertain consequent can be applied to one of the values of the dataset135 based on the CVF 128. For instance, one of the values of the dataset135 can be a numerical base value, e.g. B1, that encodes an aspect ofthe dataset 135, as mentioned above. In such cases, applying a certainconsequent of M_RULE6 176A may include performing a mathematicaloperation on the base value B1. For example, applying the certainconsequent may include multiplying the base value B1 with a number foundin the CVF 128 indicated by the certain consequent. Such a number canbe, for example, a percentage, e.g., 1.5%, 3%, 5%, and so on. Such anumber can be indicated directly by the certain rule, or be stored in aplace indicated by the certain rule, such as in the CVF 128, and so on.

As mentioned above, in some embodiments two or more digital main rulesmay be applied. For instance, the computer system 195 may recognize thatan additional condition of an additional one of the accessed CSVDR 170Ais met by at least one of the values of the dataset 135. In this examplethere would be no digital precedence rules, or the available digitalprecedence rules would not preclude both the certain digital main ruleand the additional digital main rule from being applied concurrently.Such an additional digital main rule would have an additionalconsequent.

In such embodiments, the LE 159 may be produced by the CCF 126 of thecomputer system 190 applying the certain consequent and the additionalconsequent. For instance, where the base value B1 is used, applying thecertain consequent may include multiplying the base value B1 with afirst number indicated by the certain consequent, so as to compute afirst product. In addition, applying the additional consequent mayinclude multiplying the base value B1 with a second number indicated bythe additional consequent, so as to compute a second product. And, theLE 159 may be produced by summing the first product and the secondproduct, by averaging the first product and the second product, or byperforming some other computation involving the first product and thesecond product. However, in some embodiments, when utilizing limiteddata, such as the CVF 128, the second number may not be available in theCVF 128, and thus the local estimate may be calculated instead basedsolely on the first number stored in the CVF 128, and thus produce aless accurate estimate than if the second number indicated by theadditional consequent was also used.

In embodiments, a notification 136A can be caused to be presented on thescreen 191, by the computer system 190. The notification 136A caninclude the LE 159 and/or be about an aspect of the LE 159. In theexample of FIG. 2 , a notification 136A can be caused to be transmittedby the computer system 195, for example as an answer or other responseto the received dataset 135. The notification 136 can be about an aspectof the LE 159. In particular, the notification 136A may inform about theaspect of the LE 159, namely that it has been determined, where it canbe found, what it is, or at least a portion or a statistic of itscontent, a rounded version of it, and so on. Of course, the planningshould be that the recipient of the notification 136A understands whatit is being provided.

The notification 136A can be transmitted to one of the output devicesand another device. The output device may be the screen of a local user,such as screen 191, or a remote user. The notification 136A may thuscause a desired image, message, or other such notification to appear onthe screen, such as within a Graphical User Interface (GUI) and so on.The other device can be the remote device, from which the dataset 135was received.

FIG. 3 is a diagram showing sample aspects of embodiments of the presentdisclosure involving producing, via one or more computer network calls,such as application programming interface (API) call 124 to OSP 198, amore accurate estimate (MAE) 179 of the resource, which is animprovement in automated computerized systems. The MAE 179 is producedby the computer system 195 of the OSP 198 based on the dataset 135communicated to the OSP 198 from the connector 122 of the clientcomputer system 190 via network 188 and on digital rules 170B storedremotely at the OSP 198. The MAE 179 is more accurate than the LE 159 ofFIG. 2 because, unlike the LE 159 that is produced based on the CVF 128,it is produced using data that covers all the parameters that are neededby all the digital rules 170B produce an accurate estimate of a resourcebased on the dataset 135.

The sample received dataset 135 is shown below the line 115. The dataset135 may be received by the computer system 195 in a number of ways. Insome embodiments, one or more requests may be received by the computersystem 195 via a network. In this example, a request in the form of anAPI call 124 is received by the computer system 195 via the network 188.The API call 124 has been transmitted by the client computer system 190.The dataset 135 may be sent as part of or in conjunction with the APIcall 124, such as via connector 122. In some embodiments, the dataset135 may be sent as part of or in conjunction with the API call 124. Forexample, the received API call 124 can carry one or more payloads. Insuch embodiments, the one or more payloads may be parsed by the computersystem 195 to extract the dataset 135. In this example, the payload canbe parsed by the computer system 195 to extract the dataset 135. In thisexample the single payload encodes the entire dataset 135, but that isnot required. In fact, a dataset 135 can be received from the payloadsof multiple requests or API calls. In such cases, a single payload mayencode only a portion of the dataset. And, of course, the payload of asingle request or API call may encode multiple datasets. Additionalcomputers may be involved with the network 188, some beyond the controlof the user 192 or OSP 198, and some within such control.

In embodiments, digital rules 170B may be stored at the OSP 198 andaccessed by the computer system 195. These rules 170B are digital inthat they are implemented for use by software. For example, these rules170B may be implemented within programs 131 and data 138. Digital rules170B may be accessed responsive to receiving a dataset, such as thedataset 135.

The digital rules 170 may include main rules, which can thus be accessedby the computer system 195. In this example, three sample digital mainrules are shown explicitly, namely M_RULE5 175B, M_RULE6 176B, andM_RULE7 177B. In this example, the digital rules 170 also includedigital precedence rules P_RULE2 172B and P_RULE3 173B, which can thusbe further accessed by the computer system 195. The digital rules 170may include additional rules and types of rules, as suggested by thevertical dot-dot-dots. In some embodiments, the digital rules 170B mayinclude more, or more complete, rules than the CSVDR 170A shown in FIG.2 . In such embodiments, the CSVDR 170A may be a subset of the digitalrules 170B. This may be such that the CSVDR 170A comprise a smaller datapackage, and thus more efficiently deployable to the client computersystem 190 via network 188. In other embodiments, the CSVDR 170A are thesame as the digital rules 170B.

In embodiments, a certain one of the digital main rules may beidentified from among the accessed stored rules by the computer system195. In particular, values of the dataset 135 can be tested, accordingto arrows 171B, against logical conditions of the digital main rules, asdescribed with reference to FIG. 2 , but with the computer system 195 ofthe OSP 198 performing the test instead of the CCF 126 of the clientcomputer system 190. In this example, the certain main rule M_RULE6 176Bis thus identified, which is indicated also by the beginning of an arrow178B similar to that that as described for main rule M_RULE6 176A inreference to FIG. 2 . Identifying may be performed in a number of ways,and depending on how the digital main rules are implemented in a similarmanner to that described with reference to the CSVDR 170A in FIG. 2 .

In embodiments, a notification 136B can be caused to be transmitted,e.g., via the network 188, by the computer system 195. The notification136B can be about or include an aspect of the resource, such as the MAE179. In the example of FIG. 1 , the notification 136B can be caused tobe transmitted by the computer system 195, for example as an answer orother response to the API call 124 and/or received dataset 135. Thenotification 136B can be about an aspect of the MAE 179. In particular,the notification 136B may inform about the aspect of the MAE 179, namelythat it has been determined, where it can be found, what it is, or atleast a portion or a statistic of its content, a rounded version of it,and so on. Of course, the planning should be that the recipient of thenotification 136B understands what it is being provided.

The notification 136B can be transmitted to one of an output device andanother device. The output device may be the screen of a local user or aremote user. The notification 136 may thus cause a desired image,message, or other such notification to appear on the screen, such aswithin a Graphical User Interface (GUI) on screen 191 and so on. Theother device can be the remote device, such as computer system 190, fromwhich the API call 124 and/or dataset 135 was received.

In some embodiments, to save time and/or resources, under certainconditions the CCF 126 of the client computer system 190 may decide toproduce the LE 159 shown in FIG. 2 instead of causing the MAE 179 to beproduced via the API call 124. For example, the LE 159 may be able to beproduced more efficiently or faster than the MAE 179 due to unfavorableconditions or latency of the network 188, overloading of the OSP 198 orother operating conditions or demands on the OSP 198 preventing the OSP198 from producing the MAE 179 in a timely manner. Such conditions maybe selectable by the user 192 as explained further below. Also, undercertain conditions, the CCF 126 of the client computer system 190 maydecide to produce the LE 159 shown in FIG. 2 and then cause the MAE 179to be produced via a follow-up API call 124 (e.g., when operatingconditions of the OSP 198 and/or network conditions are more favorable)for reconciliation with the MAE 179 to find discrepancies between the LE159 and the MAE 179, as explained further below.

FIG. 4 is a diagram showing sample aspects of embodiments of the presentdisclosure involving the client 193 of FIG. 3 transmitting the LE 159 tothe OSP 198 for reconciliation with the more MAE 179 to finddiscrepancies 160 between the LE 159 and the MAE 179 that is animprovement in automated computerized systems.

Under certain conditions, the CCF 126 of the client computer system 190may decide to produce the LE 159 as described with reference to FIG. 2and then cause the MAE 179 to be produced via a follow-up API call 124as described with reference to FIG. 3 (e.g., when operating conditionsof the OSP 198 and/or network conditions are more favorable) forreconciliation with the MAE 179 to find discrepancies 160 between the LE159 and the MAE 179. In the present example, the LE 159 is transmittedto the OSP 198 via network 188 for reconciliation with the MAE 179 tofind discrepancies 160 between the LE 159 and the MAE 179.

In particular, in response to the OSP 198 receiving the LE 159, theservice engine 183 computes differences between the LE 159 and the MAE179. For example, the LE 159 may have been produced by the CCF 126 ofthe client computer system 193 identifying and applying digital mainrule M_RULE6 176A of the CSVDR 170A to the dataset 135 (according toarrows 171A and 178A) based on the CVF 128. Then, via a follow-up APIcall to the OSP 198 over network 188, such as the API call 124 of FIG. 3, the CCF 126 may cause the service engine 183 of the OSP 198 to producethe MAE 179 by identifying and applying an equivalent digital main ruleM_RULE6 176B of the digital rules 170B to the dataset 135 (according toarrows 171B and 178B) based on a more accurate and/or complete set ofparameters and data values than included the CVF 128. The service engine183 may compute the differences between the LE 159 and the MAE 179,record these differences as discrepancies 160 and transmit, via network188, a notification 136C to the client computer system 190 that hasinformation about and/or includes the discrepancies. In the example, thenotification 136C can be caused to be transmitted by the computer system195, for example as an answer or other response to the receiving the LE159. The notification 136C can include and/or be about an aspect of thediscrepancies 160. In particular, the notification 136C may inform aboutthe aspect of the discrepancies 160, namely that it they have beendetermined, where they can be found, what they are, or at least aportion or a statistic of their content, a rounded version of them, andso on. In some embodiments, the OSP 198 may electronically issue one ormore resource refunds based on the discrepancies 160, such as thedifferences between the LE 159 and the MAE 179.

In some embodiments, the discrepancies 160 may also or instead becomputed or otherwise determined by the CCF 126 of the client computersystem 190. For example, the CCF 126 may compute the discrepancies 160in response to receiving the notification 136B of FIG. 3 including theMAE 179 from the OSP 198. In such embodiments, the client computersystem 190 may transmit the discrepancies 160 to the OSP 198 forverification and/or to receive a refund from the OSP 198 based on thediscrepancies 160.

FIG. 5 is a diagram showing sample aspects of embodiments of the presentdisclosure involving the client 193 of FIG. 2 receiving, from the OSP198 across the network 188, updates 165 for producing the LE 159 shownin FIG. 2 and FIG. 4 , which is an improvement in automated computerizedsystems.

It may be that the OSP 198 may obtain and/or generate updates 165 torules and associated data that may affect how an estimate of a resourceis to be computed. The OSP 198 may transmit such updates 165, such as inthe form of an updated CVF and/or updated CSVDR, to the client computersystem 190 via network 188 such that the CCF 126 of the client computersystem 190 may produce the LE 159 based on this updated information.

For example, the connector 122 may receive updates 165 from the OSP 198across the network 188, including an updated CVF that includes updatedvalues. The CCF 126 may store locally on a storage medium of thecomputer system 190 the updated CVF to replace the CVF 128. The CCF 126may produce by the CSVDR 170A and the updated values of the updated CVF,an additional LE of a resource for the dataset 135 shown FIG. 2 and FIG.4 and output the additional local estimate to the screen 191 inconjunction with the dataset 135 similarly to how the LE 159 is producedusing the original CVF 128 with reference to FIG. 2 and FIG. 4 .

FIG. 6 is a flowchart for illustrating a sample method 600 for producinga local estimate of a resource that is an improvement in automatedcomputerized systems, according to embodiments of the presentdisclosure.

Although, in the present example, the operations and methods describedwith reference to the flowcharts illustrated in FIGS. 6-8 are describedas being performed by the client computer system 190, in variousembodiments, one or more of the operations and methods described withreference to the flowcharts illustrated in FIGS. 6-8 may be performed bythe computer system 195 of the OSP 198.

The method 600 starts at 605.

At 610, the computer system 190 stores locally on a storage medium aclient computing facility (CCF) that includes digital rules.

At 615, the computer system 190 receives, from the OSP 198 across anetwork, a coarse values file (CVF) that includes values.

At 620, the computer system 190 generates a dataset that represents arelationship instance of a client entity of the computer system 190 withanother entity.

At 625, the computer system 190 produces, by the digital rules of theCCF and the values of the CVF, a local estimate of a resource for thedataset.

At 630, the computer system 190 outputs the local estimate to a localoutput device of the computer system 190 in conjunction with thedataset.

The method 600 ends at 635.

In some embodiments, the computer system 190 may first determine whetherproducing the local estimate of the resource for the dataset has beenenabled by the CCF. Producing of the local estimate is then performed ifit is determined producing the local estimate of the resource for thedataset has been enabled. If it is determined producing the localestimate of the resource for the dataset has not been enabled, then,instead of producing the local estimate, the computer system 190produces, via one or more computer network calls to the OSP 198, a moreaccurate estimate of the resource that is more accurate than the localestimate based on the dataset and digital rules stored remotely at theOSP 198. The computer system 190 receives the more accurate estimatefrom the OSP 198 and outputs the more accurate estimate to the localoutput device in conjunction with the dataset.

In some embodiments, the computer system 190 may present a selection ofoptions via a graphical user interface (GUI). The options may include,for the dataset, one or more of: producing the local estimate andreceiving the more accurate estimate. The computer system 190 receives aselection of the options. The production of the local estimate and theproduction of the more accurate estimate is then based on the selection.

In some embodiments, the computer system 190 may, after producing thelocal estimate, transmit a follow-up computer network call to the OSP198 to produce a more accurate estimate of the resource that is moreaccurate than the local estimate based on the dataset and digital rulesstored remotely at the OSP 198. In response to transmitting thefollow-up computer network call to the OSP 198, the computer system 190receives the more accurate estimate from the OSP 198.

FIG. 7 is a flowchart illustrating a sample method 700 for producing alocal estimate of a resource based on an updated CVF that is animprovement in automated computerized systems, according to embodimentsof the present disclosure.

In some embodiments, the computer system 190 may also receive, from theOSP 198 across the network, an updated CVF that includes updated valuesand store locally on the storage medium the updated CVF to replace theCVF. The computer system 190 may produce by the digital rules of the CCFand the updated values of the updated CVF, an additional local estimateof a resource for the dataset output the additional local estimate tothe local output device in conjunction with the dataset.

In particular, the method 700 starts at 705.

At 710, the computer system 190 receives, from the OSP 198 across thenetwork, an updated CVF that includes updated values.

At 715, the computer system 190 stores locally on a local storage mediumthe updated CVF to replace the CVF.

At 720, the computer system 190 produces, by the digital rules of theCCF and the updated values of the updated CVF, an additional localestimate of a resource for the dataset.

At 725, the computer system 190 outputs the additional local estimate toa local output device in conjunction with the dataset.

The method 700 ends at 730.

FIG. 8 is a flowchart illustrating a sample method 800 for computingdifferences between local estimates and more accurate estimates that isan improvement in automated computerized systems, according toembodiments of the present disclosure.

In particular, the method 800 starts at 805.

At 810, the computer system 190 determines whether local estimates areenabled. If it is determined local estimates are enabled, the method 800proceeds to 815. If it is determined local estimates are not enabled,the method 800 ends at to 845.

At 815, the computer system 190 determines whether follow-up API calls(e.g., to the OSP 198) are enabled to produce more accurate estimates.If it is determined follow-up API calls are enabled, the method 800proceeds to 820. If it is determined follow-up API calls are notenabled, the method 800 ends at to 845.

At 820, the computer system 190 determines whether scheduling input hasbeen received for performing follow-up API calls (e.g., to the OSP 198)to produce more accurate estimates. For example, the computer system 190may receive input indicating scheduling of a follow-up computer networkcall to the OSP 198. If it is determined scheduling input has beenreceived for performing follow-up API calls, the method 800 proceeds to825. If it is determined scheduling input has not been received forperforming follow-up API calls, the method 800 proceeds to 830.

At 825, the computer system 190 makes follow-up API calls (e.g., to theOSP 198) to produce more accurate estimates. In particular, the computersystem 190 will perform the follow-up computer network call to the OSP198 according to the input indicating the scheduling. For example, thescheduling may indicate that a follow-up computer network call to theOSP 198 is to occur in response to, or at a time based on, internetresponse times exceeding one or more thresholds.

At 830, the computer system 190 makes follow-up API calls (e.g., to theOSP 198) according to a default schedule in cases where it is determinedscheduling input has not been received for performing follow-up APIcalls.

At 835, the computer system 190 obtains local estimates of resources andthen, based on the follow-up API calls, obtains corresponding moreaccurate estimates from the OSP 198.

At 840, the computer system 190 computes differences between at leastsome of the local estimates produced by the computer system 190 andcorresponding more accurate estimates received from the OSP 198. Forexample, the computer system 190 may reconcile the local estimates withthe more accurate estimates to find discrepancies between the localestimate and the more accurate estimates.

The method 800 ends at 845.

Operational Examples—Use Cases

The above-mentioned embodiments have one or more uses. Aspects presentedbelow may be implemented as was described above for similar aspects.(Some, but not all, of these aspects have even similar referencenumerals.)

Referring again to FIGS. 1-5 , as an example use case, businesses, suchas client 193, may use the OSP 198 to estimate a resource (e.g., a salestax, service tax, use tax, electronic waste recycling (eWaste) fees,etc.) on transactions with customers, such as with secondary entity 196.Such estimations may be made and transmitted before, during and/or afterthese transactions. Such taxes involving transactions may be referred toherein generally as transaction taxes. Such transactions with customersare examples relationship instances with secondary entities, such assecondary entity 196, described above. The businesses may transmitinformation to the OSP 198 over network 188 via connector 122 in orderto enable the OSP 198 to produce and transmit the tax estimates back tothe businesses. This information may include, but is not limited to:data regarding the seller and recipient of the goods or servicesinvolved in the transaction; the respective locations of the seller, therecipient, and the goods and/or services; locations where the goods aredelivered or where the recipient takes possession of the goods orreceives the services; data about the goods and/or services being sold;and other transaction data. This data may be included in a dataset, suchas dataset 135 shown in FIG. 2 .

However, due to unfavorable conditions or latency of the network 188,overloading of the OSP 198 or other operating conditions or demands onthe OSP 198 preventing the OSP 198 from producing the estimates in atimely manner, a rough, locally generated tax estimate (e.g., LE 159)based on a coarse values file (e.g., CVF 128) that was previouslyreceived from the OSP 198 may be able to be produced and received by theclient computer system 190 more efficiently or faster than the moreaccurate tax estimate (e.g., MAE 179). This may be important especiallywhen sales tax estimates are needed in real time as transactions areoccurring. For example, CVF 128 may have tax rates according to zipcodes, plus one or more special variables. Still, it may be that thisinformation is not complete or fully accurate, and thus would onlyprovide approximate estimates because it does not discuss or consultother tax-related parameters, such as, for example, individual producttaxability (e.g. clothing, alcohol, etc.), tax holidays and, in anyevent, tax boundaries which do not necessarily follow the zip codes thatthe CVF 128 is based on. Also, although the CVF 128 may not include allthe parameters and values needed to provide a fully accurate taxestimate, reducing the data package size of the CVF 128 makes it moreefficiently and easily deployable to the client computer system 190 vianetwork 188.

FIG. 9 is a sample view of a User Interface (UI) 7100 of a system forestimating less-than-critical resources that provides a selectableoption to produce a local estimate of a resource based on a selection ofa degree of risk between a lower risk local estimate and a higher risklocal estimate that is an improvement in automated computerized systems,according to embodiments of the present disclosure.

There may be different outcomes (i.e., different tax estimates) based onpossible values of the information missing in the CVF 128 or rulesabsent from the CSVDR 170A. One of the estimates may be associated witha higher risk to the client 193, such as resulting in an estimation ofno tax due when it is actually due, or a tax estimated that is too low.This may result in the business having to pay the tax that should havebeen collected or being otherwise legally penalized. One of theestimates may be associated with a lower risk to the client 193, such asa small risk of legal ramifications and liability as compared to thehigher risk option.

For example, the UI 7100 may be presented by the CCF 126 of the computersystem 190 and the screen 7191 on which the UI 7100 is presented may bethe screen 191 of the computer system 190. The selectable option may beto produce the LE 159 of FIG. 2 of a tax based on a selection of adegree of risk between a lower risk local estimate and a higher risklocal estimate. The computer system 190 may receive input indicating aselection of the degree of risk between the lower risk local estimateand the higher risk local estimate. The production of the LE 159 maythen include producing, by the CSVDR 170A and the values of the CVF 128,the local tax estimate based on the selection of the degree of riskbetween the lower risk local tax estimate and the higher risk local taxestimate. For example, the CCF 126 may calculate a weighted averagebetween the lower risk local estimate and the higher risk local estimatebased on the degree of risk between the lower risk local estimate andthe higher risk local estimate selected by the user 192. In otherembodiments, the CCF 126 may select an estimate between the lower risklocal estimate and the higher risk local estimate proportional to thedegree of risk between the lower risk local estimate and the higher risklocal estimate selected by the user 192.

In the present example, the user 192 may select the degree of riskbetween the lower risk local estimate and the higher risk local estimateby sliding a graphical use interface element on UI 7100 to a location ona scale between a graphical element representing the lower risk localestimate and a graphical element representing the higher risk localestimate. However, in various other embodiments, the degree of riskbetween the lower risk local estimate and the higher risk local estimatemay be selected via other input elements such as buttons, dials, inputfields, menu items, etc.

FIG. 10 is a sample view of a UI 7600 of a system for estimatingless-than-critical resources that provides a selectable option toreceive both the LE 159 and MAE 179 via follow-up computer networkcalls, such as API call 124, to the OSP 198, which is an improvement inautomated computerized systems, according to embodiments of the presentdisclosure.

The UI 7600 may be presented by the CCF 126 of the computer system 190and the screen 7191 on which the UI 7600 is presented may be the screen191 of the computer system 190. For example, the UI 7600 may bepresented after the client 193 has opted to receive the CVF 128 toproduce the LE 159. Shown on UI 7600 is a selectable option to receiveboth the LE 159 and MAE 179 via follow-up API call 124 to OSP 198 at alater time, as described above with respect to FIGS. 3 and 4 . In UI7600, it is highly recommended that the client 193 select to receiveboth the LE 159 and MAE 179 via follow-up API call 124 to OSP 198, sothat the client 193 can further reconcile the local estimate produced.

FIG. 11 is another sample view of the UI 7600 of FIG. 10 providing aselectable option to indicate when follow-up computer network calls,such as API call 124, to the OSP 198 should be attempted, which is animprovement in automated computerized systems, according to embodimentsof the present disclosure.

The UI 7600 may be presented by the CCF 126 of the computer system 190and the screen 7191 on which the UI 7600 is presented may be the screen191 of the computer system 190. For example, the UI 7600 may bepresented after the client 193 has opted to receive the CVF 128 toproduce the LE 159. The UI 7600 indicates to the client 193 that optedto receive the CVF 128 that they will now have the option to produce LE159 instead of making API calls. However, in addition to producing theLE 159 for the client 193, the UI 7600 provides the option for theclient 193 to obtain the MAE 179 by a follow-up API call, such as APIcall 124, at a later time. Also, the UI 7600 provides the option for theclient 193 to select under what conditions the follow-up API call willbe attempted in order to obtain the MAE 179. For example, the client 193may select to have the follow-up API call attempted at a selectableparticular frequency (e.g., every 60 minutes) after the internetresponse time is over a selectable threshold (e.g., 3000 msec) forlonger than a selectable amount of time (e.g., 5 minutes). Otherselectable conditions for attempting the follow-up API calls may beselected and set in various other embodiments via UI 7600.

FIG. 12 is another sample view of a UI 7400 of a system for estimatingless-than-critical resources that provides selectable options toindicate under what conditions particular sources of resource estimateproduction are to be automatically used, which is an improvement inautomated computerized systems, according to embodiments of the presentdisclosure.

The UI 7400 may be presented by the CCF 126 of the computer system 190and the screen 7191 on which the UI 7400 is presented may be the screen191 of the computer system 190. For example, the client 193 may selectto produce local sales tax estimates versus the more accurate sales taxestimates via an API call to the OSP 198 over the network according tovarious source choice rules (SCR), which are selectably ordered byprecedence.

For example, as first precedence, according to selectable SCR1, theclient 193 may select to produce local sales tax estimates when signaledby the OSP 198. In such an embodiment, the computer system 190 mayreceive a signal from the OSP 198. The signal may set a flag value toindicate whether producing a more accurate sales tax estimate via one ormore computer network calls to the OSP 198 is allowed. In someembodiments, the signal from the OSP 198 is a warning of a potentialservice interruption of the OSP system and, in response to the signal,the flag value is set to indicate that producing the more accurateestimate via one or more computer network calls to the OSP 198 is notallowed. The flag value may indicate producing the more accurate salestax estimate via one or more computer network calls to the OSP 198 isallowed when network and operating conditions of the OSP 198 are notoverloaded. On the other hand, the flag value may be set by the OSP 198to indicate that producing a more accurate sales tax estimate via one ormore computer network calls to the OSP 198 is not allowed in response tonetwork and operating conditions of the OSP 198 indicating an imminentoverload of the network and/or OSP 198.

The computer system 190 will then produce, via one or more computernetwork calls to the OSP 198, the more sales tax accurate estimate ifparticular selectable conditions in which to produce the more accurateestimate are met (such as according to the other selectable SCR in UI7400) and the flag value indicates that producing the more accurateestimate via one or more computer network calls to the OSP system isallowed. The computer system 190 will produce the local estimate insteadof the more accurate estimate if the flag value indicates that producingthe more accurate estimate via one or more computer network calls to theOSP system is not allowed. Also, the computer system 190 may receive anall clear signal from the OSP 198 clearing the warning of the potentialservice interruption. In response to receiving the all clear signal, thecomputer system 190 may change the flag value to indicate that producingthe more accurate estimate via one or more computer network calls to theOSP 198 is allowed again.

As second precedence, according to selectable SCR2, the computer system190 will produce the local estimate of sales tax instead of the moreaccurate sales tax estimate when internet response is longer than 3,000msec, for longer than 5 minutes (includes internet down).

As third precedence, according to selectable SRC3, the computer system190 will produce the local estimate of sales tax instead of the moreaccurate sales tax estimate when a buyer adds or removes item from thecart at the online store provided by the client 193.

As fourth precedence, according to selectable SRC4, the computer system190 will produce the more accurate sales tax estimate instead of thelocal estimate of sales tax when a buyer checks out with their cart atthe online store provided by the client 193 (e.g., due to the higherrisk of charging the buyer incorrectly for sales tax rather than merelyproviding an estimate of sales tax before the buyer pays).

In various embodiments, the selectable SCR may implement a fall-backmode where the local estimate function of the CCF 126 is selected to beused only if the OSP 198 is unable to be reached within a user specifiedamount of time, such as from an e-commerce application attempting tomake a transaction.

FIG. 13 is a diagram showing a representation of an example dataset in asystem for estimating less-than-critical resources and indicating forwhich relationship instances of the dataset a local estimate wasproduced and also indicating for which relationship instances of thedataset a more accurate estimate was produced, which is an improvementin automated computerized systems, according to embodiments of thepresent disclosure.

For example, the dataset 335 may be an example of dataset 135 of FIG. 3and include data representing a set of sales transactions of client 193with secondary entity 196. In the present example, more accurate salestax estimates 379 are received for the first two transactions via atimely API call, such as API call 124 of FIG. 3 . For the remaining fivetransactions, the client computer system 190 instead produces timelyless accurate local estimates 359 of sales tax. For example, for thefirst two transactions, conditions were met according to the selectedSCR of FIG. 12 for producing accurate sales tax estimates via a timelyAPI call. However, for the remaining five transactions, conditions werenot met according to the selected SCR of FIG. 12 for producing accuratesales tax estimates via a timely API call, so the client computer system190 instead produced timely less accurate local estimates 359 of salestax for those remaining five transactions.

FIG. 14 is another sample view of a UI 7300 of a system for estimatingless-than-critical resources that provides a selectable option toindicate whether a local estimate of resources is always to be producedand whether to enable local learning functions of the system thatcompares the local estimate with results of more accurate estimates viaAPI calls when available, which is an improvement in automatedcomputerized systems, according to embodiments of the presentdisclosure. In some embodiments, the UI 7300 is generated and presentedafter or in response to the user making a selection in the UI 7400 ofFIG. 12 .

In some embodiments, using the discrepancies 160 computed in referenceto FIG. 4 based on differences between the LE 159 and MAE 179, theclient computer system 190 and/or computer system 195 may learn toimprove certain values in the CVF 128 and/or CSVDR 170A based onhistorical discrepancies involving the use of certain values orparameters in the CVF 128 and/or digital rules in the CSVDR 170A. Invarious embodiments, various machine learning and/or various artificialintelligence (AI) models may be used to train the system and perform thelearning aspects. Thus, the client 193 may select, as shown in UI 7300,to always have the local estimate produced, even when the more accurateestimate is produced first, in order to enable this learningfunctionality and improve the accuracy of the local estimates.Alternatively, the client 193 may select, via UI 7300, for the computersystem 190 to only produce the local estimate according to theselections made within the UI 7400 of FIG. 12 , which may have beendisplayed on the screen previous to the UI 7300.

FIG. 15 is a diagram showing a representation of an example dataset in asystem for estimating less-than-critical resources and discrepanciesbetween local estimates and more accurate estimates that were producedfor relationship instances of the dataset, which is an improvement inautomated computerized systems, according to embodiments of the presentdisclosure.

For example, the dataset 435 may be an example of dataset 135 of FIG. 3and include data representing a set of sales transactions of client 193with one or more customers, such as secondary entity 196. In the presentexample, more accurate sales tax estimates 479 are received for thefirst two transactions via a timely API call, such as API call 124 ofFIG. 3 . Also, for all the transactions, the client computer system 190instead produces less accurate local estimates 459 of sales tax, such asaccording to a selection made in UI 7300 to always have the localestimate produced, even when the more accurate estimate is producedfirst, in order to enable the learning functionality and improve theaccuracy of the local estimates based on discrepancies 460 between thelocal estimates 459 of sales tax and the more accurate sales taxestimates 479.

FIG. 16 is another sample view of a UI 7200 of a system for estimatingless-than-critical resources that provides a selectable option toindicate how local estimates will be determined by the system, which isan improvement in automated computerized systems, according toembodiments of the present disclosure.

The UI 7200 may be presented by the CCF 126 of the computer system 190and the screen 7191 on which the UI 7200 is presented may be the screen191 of the computer system 190. For example, sales tax may vary based onzip code and particular locations within a zip code, but in order toproduce a rough local estimate of sales tax in a timely manner withouthaving to make network calls to the OSP 198 for a more accurate salestax estimate, the client 193 may select to have the client computersystem 190 determine the local estimate of sales tax using the values ofthe CVF 128 either (i) always according to the most common zip code inthe state, or (ii) as an aggregate between extreme values. In someembodiments, the extreme values may be a location having the lowestsales tax in the state and a location having the highest sales tax inthe state, and the aggregate may be an average between those two valuesor some other aggregate value between, or otherwise based on, thoseextreme values.

FIG. 17 is a diagram showing a representation of an example dataset in asystem for estimating less-than-critical resources and discrepanciesbetween local estimates and more accurate estimates resulting fromfollow-up API calls to the OSP system that were produced for variousrelationship instances of the dataset, which is an improvement inautomated computerized systems, according to embodiments of the presentdisclosure.

For example, the dataset 535 may be an example of dataset 135 of FIG. 3and include data representing a set of sales transactions of client 193with one or more customers, such as secondary entity 196. In the presentexample, more accurate sales tax estimates 579 are received for thefirst two transactions via a timely API call, such as API call 124 ofFIG. 3 . For the remaining five transactions, the client computer system190 instead produces timely less accurate local estimates 559 of salestax. For example, for the first two transactions, conditions were metaccording to the selected SCR of FIG. 12 for producing accurate salestax estimates via a timely API call. However, for the remaining fivetransactions, conditions were not met according to the selected SCR ofFIG. 12 for producing accurate sales tax estimates via a timely APIcall, so the client computer system 190 instead produced timely lessaccurate local estimates 559 of sales tax for those remaining fivetransactions.

Additionally, for the remaining five transactions, the client computersystem 190 also produced more accurate estimates 549 via follow-upcomputer network calls, such as API call 124, to the OSP 198 asdescribed above with reference to FIGS. 3, 4, 8 and 10 . For theremaining five transactions, the client computer system 190 and/or OSP198 also generated discrepancies 560 between local estimates 559 andmore accurate estimates 549 resulting from follow-up API calls to theOSP 198. Using the discrepancies 560 computed as described withreference to FIG. 4 based on differences between the local estimates 559and more accurate estimates 549, the client computer system 190 and/orcomputer system 195 may learn to improve certain values in the CVF 128and/or CSVDR 170A based on historical discrepancies involving the use ofcertain values or parameters in the CVF 128 and/or digital rules in theCSVDR 170A.

In some embodiments, the client computer system 190 and/or computersystem 195 determines the absolute value of each of these differencesbetween the local estimates 559 and the corresponding more accurateestimates 549. If the client computer system 190 and/or computer system195 determines this absolute value is less than a threshold for a statefor very many of these differences (an amount which may be selectable bythe client 193), then for datasets for that state, the client computersystem 190 will produce the local estimate instead of producing the moreaccurate estimates 549 via API calls to the OSP 198. This process may beperformed always as selected by the client 193, or at least during hightraffic times of the network as defined, for example, according to theselections made in UI 7600 as described referencing FIG. 11 and/or UI7400 as described referencing FIG. 12 . In such embodiments, the optionhas been selected for the client computer system 190 to also producemore accurate estimates 549 via follow-up computer network calls, suchas API call 124, to the OSP 198. Otherwise, correspondingly feweroptions will be presented by the client computer system 190.

In some embodiments, if the client computer system 190 determines thelocal estimate of sales tax was higher than the resource determined bythe more accurate estimate resulting from the follow-up API call to theOSP 198, the client computer system 190 then determines that the sellerwas charged more sales tax than was due. In such cases, the clientcomputer system 190 can issue a refund to the buyer's credit card forthe excess sales tax charged. Also, in some embodiments, if the clientcomputer system 190 determines the local estimate of sales tax was lowerthan the resource determined by the more accurate estimate resultingfrom follow-up API call to the OSP 198, the client computer system 190then determines the seller was charged less sales tax than was due. As afirst option, the client 193 as the seller may swallow the loss (whichmay be negligible). As another option, the client computer system 190may attempt to charge the credit card additional sales tax, but due tothe reputational risk, the client computer system 190 may enable theclient 193 to select the first option. With either option, the CCF 126of the computer system 190 may adjust accordingly how the local estimateis to be computed going forward from the maximum and minimum tax rate asdescribed herein.

FIG. 18 is a diagram showing sample aspects of embodiments of a systemfor estimating less-than-critical resources in a use case of anembodiment that is an improvement in automated computerized systems,according to embodiments of the present disclosure.

Shown is a tax service provider 1806 (which may be an example of the OSP198 of FIGS. 1-5 ). Also shown is the SDK 125 and the connector 122 ofthe client computer system 190 FIGS. 1-5 of client 193.

As part of the CSVDR 170A and/or the CVF 128 discussed with reference toFIGS. 1-5 , the tax service provider 1806 may distribute the client sidetax rates and rules 1810, the client side tax exemptions file 1804 andthe client side tax nexus file 1802.

The client side tax rates and rules 1810 may include, for example, butis not limited to, parameters, digital rules and values such as:transaction tax rates; particular types of transaction tax rates (e.g.,a sales tax rates, service tax rates, use tax rates, electronic wasterecycling (eWaste) fees, etc.); zip codes corresponding to particulartransaction tax rates; tax jurisdictions corresponding to particulartransaction tax rates; the highest possible total collective transactiontax rate in a particular zip code or tax jurisdiction; the lowestpossible total collective transaction tax rate in a particular zip codeor tax jurisdiction; and digital rules for how and when to applyparticular tax rates. Different tax rates and rules files may also bedistributed for different types of taxes and associated locations,products or services that may trigger collection of those taxes.

The client side tax exemptions file 1804 may include, for example, butis not limited to, parameters, digital rules and values such as:particular products or services or types of products or services thatare exempt from certain transaction taxes; particular locations,regions, zones, addresses, businesses and buildings that are exempt fromcertain transaction taxes; reasons for exemptions, particular types ofbusinesses that are exempt from certain transaction taxes; and digitalrules for how and when to apply tax exemptions. The client side taxexemptions file 1804 may also or instead include just an identifier of acompany, such as that of the client 193, the associated state or taxjurisdiction associated with the company, and an exemption reason forthat company.

A seller such as the client 193 may operate tax jurisdictions that ithas a physical presence in, such as a main office, a distribution centeror warehouse, an employee working remotely, and so on. Such ties with atax jurisdiction establish a so-called physical nexus. However, a taxauthority such as a state or even a city may set its own nexus rules forwhen a business is considered to be “engaged in business” with it, andtherefore that business is subject to registration and collection ofsales or other transaction taxes. These nexus rules may includedifferent types of nexus, such as affiliate nexus, click-through nexus,cookie nexus, economic nexus with thresholds, and so on. For instance,due to economic nexus, a remote seller may owe sales tax for sales madein the jurisdiction that are a) above a set threshold volume, and/or b)above a set threshold number of sales transactions. The client side taxnexus file 1802 may include, for example, but is not limited to,parameters and values such as a binary indication of whether the clienthas established tax nexus in particular zip codes or tax jurisdictions.For example, if it has been determined the client has not establishedtax nexus in a particular zip code or tax jurisdiction, then the tax fora transaction in that zip code or tax jurisdiction may be estimatedaccording to the CSVDR 170A to be zero. The client side tax nexus file1802 may also or instead include just an identifier of a company, suchas that of the client 193, and digital rules regarding establishingnexus in a particular state or other tax jurisdiction associated withthe company.

The client side tax rates and rules 1810, the client side tax exemptionsfile 1804 and the client side tax nexus file 1802 are utilized by theSDK 125 to timely produce the local estimates of transaction taxes withthe benefit of not having to make network calls to the tax serviceprovider 1806. The client may have the option to implement the SDK 125to use some or all of the client side tax rates and rules 1810, theclient side tax exemptions file 1804 and the client side tax nexus file1802, as applicable to the client's business, individual needs and typesof transactions. In some instances the client may use the SDK 125 toimplement a relational database leveraging common relationships betweenthe client side tax rates and rules 1810, the client side tax exemptionsfile 1804 and the client side tax nexus file 1802 on which theproduction of local estimates of transactions taxes will be based. Forexample, the client side tax rates and rules 1810 and the client sidetax nexus file 1802 may both be coarsely based on the zip code of theseller and/or buyer. Thus, if the client side tax nexus file 1802indicates there has not been nexus established for a particular zipcode, then the SDK 125 need not consult the client side tax rates andrules 1810 for a transaction in that zip code because the tax may bedetermined to be zero based solely on the client not having establishednexus in the particular zip code.

The client side tax rates and rules 1810, the client side tax exemptionsfile 1804 and the client side tax nexus file 1802 may be distributed bythe tax service provider in a number of ways, including, but not limitedto, leveraging a function of the SDK 125 via connector 122 or calling anAPI of the subscription gate 1808 directly. The distribution may beperiodic, with updates. In some embodiments, the SDK 125 requests fromthe tax service provider 1806, through the subscription gate 1808, theclient side tax rates and rules 1810, the client side tax exemptionsfile 1804 and/or the client side tax nexus file 1802. In otherembodiments, the tax service provider 1806 pushes out such data perinstructions, automatically, periodically, even daily, especially duringtimes of low network traffic, or in response to a change in the tax rateor, tax rules or other applicable tax-related information. In somecases, the tax service provider 1806 pushing out such data in responseto such changes may be advantageous because it prevents the connector122 of the SDK 125 making un-necessary calls to the tax service provider1806 to pull the same data, especially if it hasn't changed. Anotheradvantage is that the information contained in the client side tax ratesand rules 1810, the client side tax exemptions file 1804 and/or theclient side tax nexus file 1802 being on the client side is not subjectto the vagaries of needing internet access to produce estimates oftransaction taxes.

FIG. 19 is a diagram showing example of parameters and associatedparameter values 1900 that may be included in a CVF of a system forestimating less-than-critical resources that is an improvement inautomated computerized systems, according to embodiments of the presentdisclosure.

For example, the CVF 128 described with respect to FIGS. 2-5 may includevalues for a zip code parameter 1902, a state parameter 1904, and anapplicable resource rate parameter (e.g., tax rate) for that zip code inthat state. Although transaction tax rates are not generally determinedper zip code, the zip code and associated tax rate indicated in the CVFmay be used as a coarse way for the CCF 126 to use CSVDR 170A toestimate the transaction tax for a particular transaction occurring in(i.e., the seller located in and/or the recipient receiving goods in) aparticular zip code without having to make network calls to the OSP 198.In various embodiments, the parameters and associated parameter values1900 may be included in the distributed client side tax rates and rules1810 of FIG. 18 . Different tables, data structures or files may beincluded in different CVFs for different types of transaction taxes withdifferent parameters applicable to the different types of transactiontaxes.

FIG. 20 is a diagram showing another example of parameters andassociated parameter values 2000 that may be included in a CVF of asystem for estimating less-than-critical resources that is animprovement in automated computerized systems, according to embodimentsof the present disclosure.

For example, instead of including a single resource rate parameter(e.g., tax rate) for the zip code in a particular state, the CVF 128described with respect to FIGS. 2-5 may include a high resource ratevalue 2002 (e.g., the highest possible total collective transaction taxrate that could exist in the zip code) and a low resource rate value2004 (e.g., the lowest possible total collective transaction tax ratethat could exist in the zip code). The CCF 126 may use CSVDR 170A toestimate the transaction tax based on the high resource rate value 2002and/or low resource rate value 2004 in a manner selectable by the client193 by using the SDK 125. For example, this may be by averaging the highresource rate value 2002 and/or low resource rate value 2004 (orestimated taxes resulting from using those rates), by selecting eitherthe high resource rate value 2002 and/or low resource rate value 2004,or based on a selected risk tolerance of the client, such as describedwith respect to FIG. 9 .

The CVF 128 described with respect to FIGS. 2-5 may also include a nexusindicator 2006 that indicates whether the client has established nexusin the particular zip code 1902, or in a tax jurisdiction within oroverlapping the associated zip code 1902. In various embodiments, thedetermination whether the client has established nexus in the particularzip code 1902 may be made by the client 193 and/or the service engine183 of the OSP 198. For example, the service engine 183 of the OSP 198may determine whether the client has established nexus in the particularzip code 1902 and include this indication in the CVF 128 and/or theclient side tax nexus file 1802 transmitted to the client 193 in anumber of ways, including, but not limited to, leveraging a function ofthe SDK 125 via connector 122 or calling an API of the subscription gate1808 directly. In some embodiments, the OSP may have previouslycommunicated to the client 193 a determination of whether the client hasestablished nexus in the particular tax jurisdiction associated with theparticular zip code 1902. For example, if it has been determined theclient has not established tax nexus in a particular zip code (e.g., zipcode 85001 as indicated in the example of parameters and associatedparameter values 2000) or tax jurisdiction, then the tax for atransaction in that zip code or tax jurisdiction may be estimatedaccording to the CSVDR 170A to be zero.

In some embodiments, the CVF 128 described with respect to FIGS. 2-5 mayalso include tax exemption data to improve the accuracy and usefulnessof the tax estimate produced locally. The tax exemption data may includefor example, but is not limited to, parameters, digital rules and valuessuch as: particular products or services or types of products orservices that are exempt from certain transaction taxes; particularlocations, regions, zones, addresses, businesses and buildings that areexempt from certain transaction taxes; particular types of businessesthat are exempt from certain transaction taxes; and digital rules forhow and when to apply tax exemptions.

In various embodiments, there may also be additional capacities providedby the CVF 128, for example if there are additional variables in the CVF128, which the estimate CSVDR 170A do or do not consider. Suchfunctionality may be implemented directly into the connector 122 orconsumed as part of the SDK 125. For example, the additional variablesfor the SDK 125 to consume via the new local estimate function mayinclude either a yes/no variable indicating whether to perform the localestimate at all or a yes/no variable to indicate to perform the localestimate only if the client computer system 190 cannot connect to theOSP 198. For example, the configuration and selection of such variablesmay be controllable via implementation of the SDK 125.

In some embodiments, the CVF 128 described with respect to FIGS. 2-5 mayalso include a tax rate of the most populated area of the given zipcode. The CCF 126 may then determine that if the combined tax rate ofthe most populated area of the given zip code is +/−0.5% of the highestcombined rate overall of the zip code, then the CCF 126 will call theOSP 198 dynamically via API to produce a more accurate estimatecalculation instead of producing the estimate of the tax locally. Also,if highest combined rate of the zip code is equal to or greater than 1%more than the lowest combined rate of the zip code based on the valuesin the CVF 128, then the CCF 126 may use the highest combined rate forthe zip code.

In some embodiments, the OSP 198 and/or local client computer 190 maykeep track of where (e.g., zip code, region, or tax jurisdiction) themost popular calls for tax estimation are for. Accordingly, OSP 198provides area files, the minimum tax rate for that area (e.g., 6%), themaximum tax rate for that area (e.g., 8%) and the tax rate most likelyapplicable to that area based on the tracked data (e.g., most likely7.4%).

In some embodiments, instead of or in addition to a minimum and maximumestimated tax amount, the estimate of the tax returned may include asingle answer with a percentage confidence. For example, a localestimate of the tax may be returned by the CCF 126, along with aparameter indicating how accurate the estimate likely is (e.g., anestimated tax with a +/−2% confidence level, using a high tax rate of0.086 and a low tax rate of 0.065).

The embodiments described above may also use synchronous or asynchronousclient-server computing techniques, including software as a service(SaaS) technique. However, the various components may be implementedusing more monolithic programming techniques as well, for example, as anexecutable running on a single CPU computer system, or alternativelydecomposed using a variety of structuring techniques known in the art,including but not limited to, multiprogramming, multithreading,client-server, or peer-to-peer, running on one or more computer systemseach having one or more CPUs. Some embodiments may execute concurrentlyand asynchronously, and communicate using message passing techniques.Equivalent synchronous embodiments are also supported. Also, otherfunctions could be implemented and/or performed by eachcomponent/module, and in different orders, and by differentcomponents/modules, yet still achieve the functions of the systems andmethods described herein.

In addition, programming interfaces to the data stored as part of thesystem controller 210 and other system components described herein maybe available by mechanisms such as through C, C++, C #, and Java APIs;libraries for accessing files, databases, or other data repositories;through scripting languages such as JavaScript and VBScript; or throughWeb servers, FTP servers, or other types of servers providing access tostored data. The databases described herein and other system componentsmay be implemented by using one or more database systems, file systems,or any other technique for storing such information, or any combinationof the above, including implementations using distributed computingtechniques.

Different configurations and locations of programs and data arecontemplated for use with techniques described herein. A variety ofdistributed computing techniques are appropriate for implementing thecomponents of the embodiments in a distributed manner including but notlimited to TCP/IP sockets, RPC, RMI, HTTP, Web Services (XML-RPC,JAX-RPC, SOAP, and the like). Other variations are possible. Also, otherfunctionality may be provided by each component/module, or existingfunctionality could be distributed amongst the components/modules indifferent ways, yet still achieve the functions described herein.

In further embodiments, this application also discloses the following.There are many types of taxes for businesses. Such taxes include salestax, use tax, excise tax, value-added tax, industry-specific taxes,cross-border taxes, and so on (collectively referred to herein as“transaction taxes”). Further, for a single transaction, taxes may bedue to more than one tax jurisdiction, such as different states,localities within the states, counties, cities, municipalities, etc.

Determining the taxes due is often very complex. There are over 10,000tax jurisdictions in the US, and almost 10 million taxability rulesrelated to various products and services. Complexities in determiningthe sales tax due may arise from the location of the buyer, the seller,a distributor, etc. For example, some state and local authorities taxhave origin-based rules, which means that a sales tax is charged fromthe seller's location; other state and local authorities tax havedestination-based rules, which means that a sales tax is charged fromthe buyer's location. Additional complexities arise from the fact thatdifferent tax jurisdictions charge different percentage rates. Thesedifferent tax jurisdictions can be different states, counties, cities,municipalities, special taxing jurisdictions, and so on.

In addition to calculating the cost of the tax, sellers of goods andservices are subjected to many requirements about the taxes they mustcollect and remit. In particular, a seller must determine whether, andwhen, they must collect and remit transaction taxes in each taxjurisdiction. For example, for each state, a seller may need to registerwith that state's taxing agency, set up internal processes forcollecting sales tax in accordance with the tax rules of the state, keeprecords for the collected sales tax, file reports with the state, andfinally pay the tax to the state. In the U.S., retailers must have somekind of presence in a state before that state can require that retailerto collect and remit sales tax from buyers in that state. With theSupreme Court ruling in the South Dakota v. Wayfair case, not only doesphysical presence (such as a location, employee or inventory), but“economic” presence in a state may create sales tax nexus. In otherwords, due to the Wayfair ruling, even if a retailer does not have aphysical presence in a state, if the retailer passes a state's economicthreshold, for example, for total revenue or number of transactions inthat state, the retailer is legally obligated to collect and remit salestax to that state. However, different states have different thresholdsfor determining whether there is an economic nexus, which provides aproblem for retailers in determining whether they are compliant with thetax rules in various jurisdictions, especially when the retailers haveever changing total revenue and numbers of transactions in variousdifferent jurisdictions. Determining tax compliance under suchcircumstances for multiple retailers in various different jurisdictionsaccording to the various different rules for the different taxjurisdictions and communicating such information to the retailers orother entities in real-time or near real time as transactions areoccurring and nexus rules are changing presents a technical problem inorder to do so in a timely and efficient manner over computer networksand in a way that integrates well into existing technical environmentsin which tax assistance is provided. The present disclosure providessystems and methods that solve this technical problem by increasing thespeed, efficiency and accuracy of such specialized software platformsand computer networks.

FIG. 21 is a block diagram showing an example configuration of a system2100 working with a new service engine 2142 that generates taxcompliance data 22180, according to various embodiments of the presentdisclosure.

A sample customer entity 2119 includes a computer 2112, and a user 2192who may use computer 2112. Both could be located within a physical siteof the customer entity 2119, but that is not necessary. More detailsabout computer 2112 are provided with reference to FIG. 22 .

In this example, a network 2194 is a communications network. Network2194 can be any type of network, such as a local area network (LAN), ametropolitan area network (MAN), a wide area network (WAN), or theinternet. In some embodiments, network 2194 is considered to be thecloud. An Enterprise Resource Planning (ERP) system 2121 may also bewithin network 2194, if it is the cloud, or accessible by computer 2112via network 2194.

In this example, a software service platform 2140 is implemented by aserver computer 2141 and a database 2146 storing data. Software serviceplatform 2140 can be implemented in the cloud, on the premises of aprovider, in a combination of the two, and so on. Of course, additionalserver computers may be used for a single service, for example in apeer-to-peer configuration, with the operations of the servicedistributed among them. The server computers can be located at a singlegeographic location or be distributed across multiple locations.Similarly, additional databases may be used for the service, and so on.

Server computer 2141 is configured, by software, to implement a serviceengine 2142. Service engine 2142 is configured to perform a predefinedservice. The service can be a computation, a search, a verification, aregistration, a payment, a notification, generation of specializedinformation and so on. According to various embodiments of the presentdisclosure, the service may be determining or generating informationabout potential lack of tax compliance of customer entity 2119 invarious jurisdictions based on rules about establishing nexus forpurposes of remitting transaction tax in the jurisdictions and/ortransmitting a notification about the generation of the information. Insome embodiments, the transmission of such information may alert thecustomer entity 2119 of the potential lack of tax compliance. The taxcompliance data 2180 may be or include such information about potentiallack of tax compliance.

In the context of FIG. 21 , user 2192 desires the service, and may evenpay for it. User 2192 uses computer 2112 to access network 2194 and,from network 2194, to access software service platform 2140. It will beappreciated that, in some contexts, service engine 2142 performs cloudcomputing and is provided as software as a service (SaaS). Moreover,computer 2112 can be viewed as a client computer from the perspective ofsoftware service platform 2140.

The service of service engine 2142 can be performed responsive toservice engine 2142 being properly invoked. While being performed, theservice may use data from database 2146.

Server computer 2141 further hosts a service engine (SE) ApplicationProgramming Interface (API) 2179. In some embodiments, SE API 2179 isconfigured to invoke service engine 2142 to perform its service, whenproperly requested. In various embodiments, service engine 2142 mayperform its service without invocation by SE API 2179. For example,service engine 2142 may also or instead automatically invoke itself toperform the applicable service periodically and/or in response to one ormore various conditions being satisfied, including, but not limited to,one or more of: a detected change or update to stored rules aboutestablishing nexus for purposes of remitting transaction tax in acertain tax jurisdiction; a detected change or update to a monetaryamount of sales of the customer entity 2119 that are associated with acertain tax jurisdiction; a detected change or update to a volume ofsales transactions of the customer entity 2119 that are associated witha certain tax jurisdiction; one or more thresholds being met, within apredetermined threshold of being met, or being exceeded regarding salesassociated with establishing nexus for purposes of remitting transactiontax in a certain tax jurisdiction; and conditions indicated by storedpreferences of customer entity 2119.

SE API 2179 is configured to receive a request 2171, which is shown asan arrow. Request 2171 may be transmitted via network 2194. Request 2171may have been ultimately caused to be generated by computer 2112, forexample as operated by user 2192. In some embodiments, request 2171 istransmitted via network 2194 directly to SE API 2179. In otherembodiments, computer 2112 causes ERP system 2121 to transmit request2171. In yet other embodiments, ERP system 2121 originates request 2171on behalf of customer entity 2119.

Request 2171 may also include associated request data 2172. When SE API2179 receives request 2171 with its request data 2172, it invokesservice engine 2142. When thus invoked, service engine 2142 may performits service using request data 2172. In response, SE API 2179 can beconfigured to transmit a response 2174, also shown as an arrow. Response2174 may include response data 2175 that arises out of the service, suchas a computed result, a confirmation, and so on. Response 2174 can betransmitted back to the sender of request 2171, or as otherwisedirected. In some embodiments, the request 2171 may be automaticallygenerated and transmitted, such as by the ERP system 2121 and/orcomputer 2112 in response to one or more various conditions beingsatisfied, including, but not limited to, one or more of: a detectedchange or update to stored rules about establishing nexus for purposesof remitting transaction tax in a certain tax jurisdiction; a detectedchange or update to a monetary amount of sales of the customer entity2119 that are associated with a certain tax jurisdiction; a detectedchange or update to a volume of sales transactions of the customerentity 2119 that are associated with a certain tax jurisdiction; one ormore thresholds being met, within a predetermined threshold of beingmet, or being exceeded regarding sales associated with establishingnexus for purposes of remitting transaction tax in a certain taxjurisdiction; and conditions indicated by stored preferences of customerentity 2119.

In response to such a request being automatically generated, or inresponse to the service engine 2142 invoking itself, the service engine2142 may generate and/or transmit tax compliance data 22180. Forexample, tax compliance data 22180 may be or include information aboutpotential lack of tax compliance of customer entity 2119 in variousjurisdictions based on rules about establishing nexus for purposes ofremitting transaction tax in the jurisdictions and/or a notificationabout the generation of the information. In an example embodiment, thetax compliance data 22180 may be or include an alert or othernotification that alerts the customer entity 2119 entity of thepotential lack of tax compliance. In some embodiments, the taxcompliance data 22180 may be used to update information regarding thepotential lack of tax compliance for a certain tax jurisdiction withinan account associated with the customer entity 2119. The accountassociated with the customer entity 2119 may be accessible by thecustomer entity 2119 via a client computing device, for example, thecomputer 2112, wherein the updated information regarding the potentiallack of tax compliance is for display on a user interface associatedwith the account. Such a user interface may, in various embodiments, bea user interface of the server computer 2141, computer 2112, and/or acomputer in ERP system 2121, and so on. Furthermore, the accountassociated with the customer entity 2119 may be managed, stored and/oraccessible by the server computer 2141, computer 2112, and/or a computerin ERP system 2121, and so on.

Computer program code for carrying out operations for aspects of thepresent disclosure may be written in any combination of one or moreprogramming languages, including an object-oriented programming languagesuch as Java, Smalltalk or the like, and/or conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages such as C++, C sharp, etc. Portions of the programcode may be executed on server computer 2141, computer 2112, a computerin ERP system 2121, and so on.

Additional details about the components of FIG. 21 , which may be knownto some, are provided near the end of this description, for notinterrupting the flow of this description at this stage.

FIG. 22 is a block diagram showing more details of a computer 2112 of anexample customer entity 2119 of FIG. 21 , with reference to thecommunication network 2194 and the software service platform 2140,according to various embodiments of the present disclosure.

FIG. 22 shows customer entity 2119 of FIG. 21 , along with more sampledetails for computer 2112. Computer 2112 may be a desktop computer, alaptop computer, a tablet computer, a mobile phone, and so on.

Computer 2112 includes a processor 2214. Computer 2112 also includes asystem bus 2232 that is coupled to processor 2214. System bus 2232 canbe used by processor 214 to control and/or communicate with othercomponents of computer 2112.

Computer 2112 additionally includes a network interface 2234 that iscoupled to system bus 2232. Network interface 2234 can be implemented bya hardware network interface, such as a network interface card (NIC),wireless communication components, cellular communication components,Near Field Communication (NFC) components, Bluetooth® components such asBluetooth® Low Energy, Wi-Fi® components, etc. Of course, such ahardware network interface may have its own software, and so on. Networkinterface 2234 can access network 2194.

Also shown is a tax compliance client 2282 residing in system memory2248, which may comprise computer-executable instructions executed byprocessor 2214 to invoke or otherwise obtain services of the softwareservice platform 2140 provided by the service engine 2142 running onserver computer 2141 of the software service platform 2140. For example,the tax compliance client 2282 may obtain and/or invoke the softwareservice platform 2140 to generate and/or transmit tax compliance data22180. In some embodiments, the tax compliance client 2282 may generatea user interface for and/or provide access to an account associated withthe customer entity 2119 through which the tax compliance data 22180 forthe customer entity 2119 may be accessible by the customer entity 2119via the computer 2112. For example, updated information regarding thepotential lack of tax compliance of the customer entity 2119 may bedisplayed via the tax compliance client 2282 on a user interfaceassociated with the account and/or the tax compliance client 2282. Thetax compliance client 2282 may, in various embodiments, be part of orintegrated with the browser 2281. In other embodiments, the browser 2281may be or perform the operations of the tax compliance client 2282, forexample, when the software service platform 2140 provides web-basedservices.

In some embodiments, the tax compliance client 2282 may communicateand/or obtain services of ERP applications (e.g., ERP system 2121),accounting applications, ecommerce applications and/or otherapplications remote from or resident on the computer 2112. For example,the tax compliance client 2282 may cause ERP system 2121 to transmit arequest or other information to the software service platform 2140 thatinvokes services of the software service platform 2140 to be provided tothe tax compliance client 2282 and/or ERP system 2121. For example, suchinformation may include information indicative of one or more variousconditions being satisfied, including, but not limited to, one or moreof: a detected change or update to stored rules about establishing nexusfor purposes of remitting transaction tax in a certain tax jurisdiction;a detected change or update to a monetary amount of sales of thecustomer entity 2119 that are associated with a certain taxjurisdiction; a detected change or update to a volume of salestransactions of the customer entity 2119 that are associated with acertain tax jurisdiction; one or more thresholds being met, within apredetermined threshold of being met, or being exceeded regarding salesassociated with establishing nexus for purposes of remitting transactiontax in a certain tax jurisdiction; and conditions indicated by storedpreferences of customer entity 2119. As another example, the taxcompliance client 2282 may request, or cause ERP system 2121 to request,transaction data regarding sales of the customer entity 2119 from theERP system 2121, accounting applications, ecommerce applications and/orother applications for purposes of transmitting such transaction data tothe software service platform 2140, such that the software serviceplatform 2140 can use such data to determine potential lack of taxcompliance in various jurisdictions for the customer entity 2119. In yetother embodiments, ERP system 2121 originates transmitting a request ortransmitting of other information on behalf of customer entity 2119.

Additional details about FIG. 22 are provided near the end of thisdescription, for not interrupting the flow of this description at thisstage.

FIG. 23 is a block diagram showing an example software architectureworking with a tax compliance information generation engine 2382,according to various embodiments of the present disclosure.

In this example, a software-implemented tax-assisting service platform2340 is configured to provide tax-related services. These services mayinclude determining potential lack of tax compliance in variousdifferent jurisdictions for the customer entities 2310, generatinginformation regarding potential lack of tax compliance of the entity forthe various tax jurisdictions, and/or transmitting one or morenotifications about the generation of the information. For example, sucha notification may be a notification to a particular customer entity2311 that there is a potential lack of tax compliance of that customerentity 2311 in a certain tax jurisdiction. In some embodiments, theseservices may also include performing tax calculations and performingaddress validation for customer entities 2310. Any one of samplecustomer entities 2311, 2312, 2313, . . . may be as described forcustomer entity 2119. These customer entities 2310 may access asoftware-implemented tax-assisting service platform 2340, for receivingits tax-related services.

Aspects of FIG. 23 may be implemented by components described and shownelsewhere in this document, for example with reference to FIG. 21 andFIG. 22 . For instance, in some embodiments, customer entities 2310access tax-assisting service platform 2340 fully directly, for exampleas is shown for customer entity 2313. In other embodiments, thisaccessing is performed at least in part indirectly, for example by usingEnterprise Resource Planning (ERP) systems 2321, 2322. In this example,ERP system 2321 has a database 2328 that stores customer data 2329 ofcustomer entity 2311, such as sales data or other transaction data. Forexample, such sales data may be used by the tax compliance informationgeneration engine 2382 data to determine potential lack of taxcompliance in various tax jurisdictions 2330 for the customer entities2310. In this example, tax-assisting service platform 2340 includes adatabase 2348, and customer entity 2311 has stored their own customerprofile 2341 in database 2348.

Tax-assisting service platform 2340 includes a tax content managementcomponent 2344 for use by TAE 2342 and the tax compliance informationgeneration engine 2382. Tax content management component 2344 mayreceive tax information from one or more tax jurisdictions 2330, such assample tax jurisdictions 2331, 2332, 2333, . . . . Tax contentmanagement component 2344 includes a database 22346 for storing thereceived tax information in the form of tax rules, rates, exemptions,etc. For example, the database 22346 may store rules about establishingnexus for purposes of remitting transaction tax in the various taxjurisdictions 2330. In some embodiments, such rules are rules aboutmeeting or exceeding one or more thresholds regarding sales over aperiod of time.

Tax-assisting service platform 2340 includes tax-assisting engines 2342.In some embodiments, TAE 2342 includes a tax computation engine 2353,and even an address validation engine 2356.

In this example, tax-assisting engines 2342 may be invoked via a TAEApplication Programming Interface (API) 2379. Only one TAE API 2379 isshown implemented here, while multiple ones may be implemented instead,for example one for invoking each of tax computation engine 2353 andaddress validation engine 2356. In this example, TAE API 2379 isconfigured to receive a request 2371 or other information from ERP 2321.Request 2371 has data 2372 of customer entity 2311. Data 2372 may belooked up from customer data 2329 in database 2328. In variousembodiments, data 2372 may also or instead be transmitted to one or moreof the tax-assisting engines 2342 in response to a request from therespective tax-assisting engine. In some embodiments, data 2372 may alsoor instead be pushed to one or more of the tax-assisting engines 2342from one or more of the customer entities 2310 and/or ERP system 2321,such as in response to the customer data 2329 being updated or changed,or on a periodic basis. In response to receiving request 2371 with itsdata 2372, TAE API 2379 invokes one of tax-assisting engines 2342 toperform its service. Then, TAE API 2379 is configured to transmit aresponse 2374. Response 2374 can be transmitted back to the sender ofrequest 2371, or otherwise.

In some embodiments, customer data 2329 may be pushed to the taxcompliance information generation engine 2382 from one or more of thecustomer entities 2310 and/or ERP system 2321, such as in response tothe customer data 2329 being updated or changed, or on a periodic basis.In response to receiving this information the tax compliance informationgeneration engine 2382 may perform its service and send the taxcompliance data 2180. The tax compliance data 2180 may be transmittedback to the sender of the customer data 2329, to a correspondingcustomer entity 2310, or otherwise. In various embodiments, the taxcompliance information generation engine 2382 may also or insteadautomatically invoke itself to perform the applicable service inresponse to one or more various conditions being satisfied, including,but not limited to, one or more of: a detected change or update tostored rules about establishing nexus for purposes of remittingtransaction tax in a certain tax jurisdiction of tax jurisdictions 2330;a detected change or update to a monetary amount of sales, that areassociated with a certain tax jurisdiction of tax jurisdictions 2330, ofone or more of the customer entities 2310; a detected change or updateto a volume of sales transactions, that are associated with a certaintax jurisdiction of tax jurisdictions 2330, of one or more of thecustomer entities 2310; one or more thresholds being met, within apredetermined threshold of being met, or being exceeded regarding salesassociated with establishing nexus for purposes of one or more of thecustomer entities 2310 remitting transaction tax in a certain taxjurisdiction of tax jurisdictions 2330; and conditions indicated bystored preferences of one or more of the customer entities 2310. Forexample, such stored rules, including the thresholds, may be stored inthe database 2346 of the tax content management component 2344 andaccessible by the tax compliance information generation engine 2382.Also, records of the sales transactions for the customer entities 2310may comprise and/or be part of the customer data 2329 and transmitted tothe tax compliance information generation engine 2382. The storedpreferences of one or more of the customer entities 2310 may alsocomprise and/or be part of the customer data 2329 and transmitted to thetax compliance information generation engine 2382.

In some embodiments, the customer data 2329 may be automaticallygenerated and/or transmitted to the tax compliance informationgeneration engine 2382, such as by the ERP system 2321 and/or one ormore of the customer entities 2310 in response to one or more variousconditions being satisfied, including, but not limited to, one or moreof: a detected change or update to stored rules about establishing nexusfor purposes of remitting transaction tax in a certain tax jurisdictionof tax jurisdictions 2330; a detected change or update to a monetaryamount of sales, that are associated with a certain tax jurisdiction oftax jurisdictions 2330, of one or more of the customer entities 2310; adetected change or update to a volume of sales transactions, that areassociated with a certain tax jurisdiction of tax jurisdictions 2330, ofone or more of the customer entities 2310; one or more thresholds beingmet, within a predetermined threshold of being met, or being exceededregarding sales associated with establishing nexus for purposes of oneor more of the customer entities 2310 remitting transaction tax in acertain tax jurisdiction of tax jurisdictions 2330; and conditionsindicated by stored preferences of one or more of the customer entities2310.

In response to such the customer data 2329 being automatically generatedand/or transmitted to the tax compliance information generation engine2382, or in response to the tax compliance information generation engine2382 invoking itself when certain conditions are satisfied, the taxcompliance information generation engine 2382 may generate and/ortransmit tax compliance data 2180 based on received customer data 2329.For example, tax compliance data 2180 may be or include informationabout potential lack of tax compliance of one or more customer entities2310 in various jurisdictions 2330 based on rules about establishingnexus for purposes of remitting transaction tax in the jurisdictions.Also, tax compliance data 2180 may be or include a notification aboutthe generation of the information. In an example embodiment, the taxcompliance data 2180 may be or include an alert or other notificationthat alerts one or more of the customer entities 2310 of the potentiallack of tax compliance in one or more of the tax jurisdictions 2330. Forexample, the tax compliance information generation engine 2382 mayperiodically, or upon the customer data 2329 being updated, receivecustomer sales data that consists or is included in the customer data2329 regarding sales of customer entity 2311 in one or more of taxjurisdictions 2330. The tax compliance information generation engine2382 may then compare the sales data of the customer data 2329 againstrules stored in database 2346 which are about establishing nexus forpurposes of remitting transaction tax in each of the tax jurisdictions2330. If, for example, based on the sales data included in the customerdata 2329, the tax compliance information generation engine 2382determines that the volume of sales transactions of customer entity 2311meet, are within a predetermined threshold of meeting, or exceed athreshold indicated by the rules regarding establishing an economicnexus for tax jurisdiction 2331, then the tax compliance informationgeneration engine 2382 may transmit a notification to customer entity2311 that there is a potential lack of tax compliance for customerentity 2311 in tax jurisdiction 2331. This notification may be, or bepart of the tax compliance data 2180. In various embodiments, the taxcompliance information generation engine 2382 may perform such a servicebased on monitoring updates to the rules stored in database 2346 andmonitoring the sales data of the customer data 2329 for each of thecustomer entities 2310 for each of the tax jurisdictions 2330 withoutneeding to receive a specific request for such a service.

In some embodiments, the tax compliance data 2180 may be used to updateinformation regarding the potential lack of tax compliance for one ormore of the tax jurisdictions 2330 within an account associated with theone or more customer entities 2310. For example, an account associatedwith the customer entity 2311 may be associated with or include customerprofile 2341 and accessible by the customer entity 2311 via thetax-assisting service platform 2340, wherein the updated informationregarding the potential lack of tax compliance is for display on a userinterface associated with the account. Furthermore, the accountassociated with the customer entity 2311 may be managed, stored and/oraccessible by the customer entity 2311, the tax-assisting serviceplatform 2340, and/or the ERP system 2321.

If tax computation engine 2353 is invoked by request 2371, it maycalculate a tax liability of an amount of tax due, based on data 2372.In that case, response 2374 includes a component of a tax liability 2375that indicates the calculated amount.

If address validation engine 2356 is thus invoked by request 2371, itmay perform an address-validation process, based on data 2372. In thatcase, response 2374 includes a component of an address feedback 2377.The latter can be a message that an address is valid, or not, or proposea different address.

In some embodiments, tax-assisting service platform 2340 may perform avariety of services in addition to what is described above. For oneexample, tax-assisting service platform 2340 may accumulate and storecustomer sales data 2372.

In another example, tax-assisting engines 2342 and/or the tax complianceinformation generation engine 2382 may further include one or moreadditional engines and/or functional components than are shown in theexample of FIG. 23 . Such additional engines and/or functionalcomponents, upon being invoked, can perform additional tax-relatedservices, such as: a) register one or more of customer entities 2310with one or more appropriate tax jurisdictions 2330, b) generate taxreturns, i.e., prepare forms for filing by customer entities 2310, c)file electronically such returns with the appropriate ones of taxjurisdiction(s) 2330, and so on. In some embodiments, one or more ofsuch services may be performed by the TAE 2342 and/or the tax complianceinformation generation engine 2382 for one or more of the customerentities 2310, or a notification may be transmitted to one or more ofthe customer entities 2310 that such services are available orrecommended, in response to a determination by the tax complianceinformation generation engine 2382 that there exists a potential lack oftax compliance for the one or more of the customer entities 2310.

FIG. 24 is a flow diagram of an example process 2400 and correspondingdata flow for transmitting notifications about information regardingpotential lack of tax compliance, according to various embodiments ofthe present disclosure.

At 2402, the tax compliance information generation engine 2382 of FIG.23 may compile transaction data of customer entities, such as customerentities 2310 of FIG. 23 . For example, such transaction data mayinclude data representing, for each of the customer entities 2310, amonetary amount of sales (e.g., revenue) associated with one or more ofthe tax jurisdictions 2330 and/or a volume of sales transactions (e.g.,number of sales transactions) associated with one or more of the taxjurisdictions 2330. The tax compliance information generation engine2382 may compile such data from one or more sources, including, but notlimited to, data customer data 2329 from database 328 and/or ERP system322 of FIG. 23 .

At 2404, the tax compliance information generation engine 2382 mayaggregate and apportion geographically the compiled transaction data toproduce a record of aggregate transactions 2410. For example, to producethe record of aggregate transactions 2410, all sales made by customerentity 2311 of FIG. 23 over a specific period of time to purchasers inTexas may be apportioned to Texas for customer entity 2311 and all salesmade by customer entity 2312 of FIG. 23 over a specific period of timeto purchasers in Rhode Island may be apportioned to Rhode Island forcustomer entity 2312. Such data may be organized by total revenue and/ortotal transactions geographically per jurisdiction and per customerentity. Such data may also be organized according to other criteria,including, but not limited to: type of goods, products or services sold;exempt goods, products or services; date of transaction; evaluationperiod; location goods shipped to; location of seller; location of buyerand type of transaction. The tax compliance information generationengine 2382 may change the compiling, including organization, of suchdata based on corresponding changing rules, about establishing nexus forpurposes of remitting transaction tax in the plurality of taxjurisdictions 2330. Such rules may include economic nexus requirements,for each jurisdiction and the tax compliance information generationengine 2382 may monitor such changes in the rules for each jurisdictionand update the rules accordingly. For example, the tax complianceinformation generation engine 2382 may access the rules from one or moresources, including, but not limited to, tax jurisdictions 2330 of FIG.23 . Such rules and corresponding updates may be stored in database2346.

At 2406 the tax compliance information generation engine 2382 maycompare the record of aggregate transactions 2410 for one or morecustomer entities 2310 to updated rules about establishing nexus forpurposes of remitting transaction tax in the plurality of taxjurisdictions, which may include statutory rule threshold records 2408that include rules regarding a monetary amount of sales that areassociated with each of various tax jurisdictions and/or a volume ofsales transactions that are associated with each of various taxjurisdictions. Below are some examples of such rules for a sample groupof individual tax jurisdictions in the U.S.

Idaho

Effective date: Jun. 1, 2019Included transactions: Cumulative gross receipts from sales includingtaxable products and taxable services delivered into the stateTreatment of exempt transactions: Exempt sales and exempt services areincluded in the threshold countTrigger: Sales onlySales/transactions threshold: $100,000Evaluation period: Threshold applies to the current or precedingcalendar year.

New Mexico

Effective date: Jul. 1, 2019Included transactions: Taxable gross receipts from taxable sales,taxable services, leases, and licenses of products, and sales oflicenses and services of licenses for use of real property sourced tothe stateTreatment of exempt transactions: Exempt sales and exempt services arenot included in the threshold countTrigger: Sales onlySales/transactions threshold: $100,000Evaluation period: Threshold applies to the previous calendar year

Rhode Island

Effective date: Jul. 1, 2019Included transactions: Sales of tangible personal property, prewrittencomputer software, and vendor-hosted prewritten software deliveredelectronically or by load and leave, and/or taxable servicesTreatment of exempt transactions: Exempt sales are included but exemptservices are not included in the threshold countTrigger: Sales or transactionsSales/transactions threshold: $100,000 or 200 transactionsEvaluation period: Threshold applies to the preceding calendar year

Texas

Effective date: Oct. 1, 2019Included transactions: Sales of products and taxable services into thestateTreatment of exempt transactions: Exempt sales and exempt services areincluded in the threshold countTrigger: Sales onlySales/transactions threshold: $500,000Evaluation period: Threshold applies to the previous 12-months, with theinitial 12 calendar months beginning Jul. 1, 2018 through Jun. 30, 2019

Virginia

Effective date: Jul. 1, 2019Included transactions: Gross revenue from retail sales and taxableservices into the state Treatment of exempt transactions: Exempt salesand exempt services are not included in the threshold countTrigger: Sales or transactionsSales/transactions threshold: $100,000 or 200 transactionsEvaluation period: Threshold applies to the current or previous calendaryear

For example, the tax compliance information generation engine 2382 mayfind in the record of aggregate transactions 2410 that customer entity2311 has total sales of $550,000 of products and taxable services intoTexas in the 12 months beginning Jul. 1, 2018 through Jun. 30, 2019. Thetax compliance information generation engine 2382 may then search thestatutory rule threshold records 408 and find that the statutorythreshold for Texas is $500,000. The tax compliance informationgeneration engine 2382 may then compare the $550,000 in total sales intoTexas for customer entity 2311 to the statutory threshold for Texas of$500,000 and record that it exceeds this statutory threshold for Texas.The tax compliance information generation engine 2382 may perform suchcomparisons for various different customer entities 2310 for variousdifferent jurisdictions 2330. For example, the tax complianceinformation generation engine 2382 may find in the record of aggregatetransactions 2410 that customer entity 2312 has a total of 185transactions for sales of tangible personal property into Rhode Islandin the preceding calendar year. The tax compliance informationgeneration engine 2382 may then search the statutory rule thresholdrecords 2408 and find that the statutory threshold for Rhode Island is$100,000 total sales or 200 transactions. The tax compliance informationgeneration engine 2382 may then compare the 185 total number oftransactions apportioned to Rhode Island for customer entity 2312 to thestatutory threshold for Rhode Island of 200 transactions and record thatit is approaching this statutory threshold for Rhode Island (e.g.,within a threshold number of 20 transactions of the 200 transactionthreshold). Other thresholds may be used to determine whether thestatutory threshold is being approached and such thresholds may beselectable by the customer entity and/or the tax compliance informationgeneration engine 2382.

The comparison may include comparison of data representing variousdifferent other or additional criteria, which may, in some embodiments,be indicated by or otherwise based on the particular rules for specificjurisdictions including, but not limited to: type of goods, products orservices sold; exempt goods, products or services; date of transaction;evaluation period; location goods shipped to; location of seller;location of buyer and type of transaction.

Based on such comparison, the tax compliance information generationengine 2382 may determine which records of the record of aggregatetransactions apportioned geographically include transactions that meet,are within a predetermined threshold of meeting, and/or exceed one ormore thresholds regarding sales for one or more of the correspondingindividual tax jurisdiction associated with the geographical area. Forexample, the tax compliance information generation engine 2382 maygenerate an aggregate of records which meet, exceed or are approachingstatutory thresholds 2414 for each jurisdiction for each customerentity. Also, in some embodiments, the tax compliance informationgeneration engine 2382 may first check the statutory rule thresholdrecords 2408 and then compare against the record of aggregatetransactions 2410 to determine whether there are any records which meet,are within a predetermined threshold of meeting, and/or exceed one ormore thresholds.

At 2416, the tax compliance information generation engine 2382 may thentransmit corresponding notifications to each of the customer entitieswhich, according to the aggregate of records, have transactions thatmeet, exceed or are approaching statutory thresholds for one or more ofthe corresponding individual tax jurisdiction. For example, thenotification may indicate to the customer entity that there is apotential lack of tax compliance of the entity for the specificcorresponding tax jurisdictions.

In the present example, the tax compliance information generation engine2382 may transmit a notification to customer entity 2311 indicating thatthere is a potential lack of tax compliance in Texas based on the resultof the comparison by the tax compliance information generation engine2382 that indicates customer entity 2311 exceeds the statutory thresholdof $500,000 in total sales for the preceding 12-month period in Texas.Also, the tax compliance information generation engine 2382 may transmita notification to customer entity 2312 indicating that there is apotential lack of tax compliance approaching in Rhode Island based onthe result of the comparison by the tax compliance informationgeneration engine 2382 that indicates customer entity 2312 isapproaching (e.g., within a threshold number of 20 transactions) thestatutory threshold for Rhode Island for total number of transactions inthe preceding calendar year.

Whether, when and how to receive notifications and which thresholds touse may be selectable by the individual customer entity and/or taxcompliance information generation engine 2382. In various embodiments,such selectable features may include selectable items for amounts forsales revenue, number of transactions, number of jurisdictions, specificjurisdictions, types of transactions, periods of time, time of year,time of month, “notice and report” thresholds, etc. For example,particular customer entity 2311 may select to receive notifications whencustomer entity 2311 is within a selectable $20,000 threshold of meetingany statutory threshold for any jurisdiction. Other customer entitiesmay select to receive notifications only when the threshold for aparticular jurisdiction is met or exceeded. Notifications may betransmitted or initiated by various electronic techniques, including,but not limited to: email, updates to user accounts, text messages,automated phone calls, chat messages, web-based messages, desktopcomputer alerts, pop-up messages or alerts, mobile device messages,mobile device applications, etc. In some embodiments, a message may beelectronically initiated by the tax compliance information generationengine 2382 to be sent by mail or courier to an address selected by thecustomer entity. In some embodiments, the notifications do not indicatethere is a potential lack of tax liability, but just that there is anotification available for the customer entity and may includeinstructions or a link for receiving or otherwise accessing furtherinformation, including information regarding potential lack of taxcompliance. In some embodiments, the notification regarding potentiallack of tax compliance may include or provide access to a notificationregarding a potential lack of tax compliance regarding reporting,collecting, and/or remitting transaction taxes for individualjurisdictions.

Such notifications may also include some or all of the results andunderlying data involved in the comparison of the record of aggregatetransactions 2410 to updated rules, and which transactions of thecustomer entity caused the determination of potential lack of taxcompliance. Additionally, audit records 2412 of the aggregation andapportionment of transaction data 2404, the comparison to statutorythresholds 2406 and the transmission of notifications 2416 may begenerated and stored by the tax compliance information generation engine2382, and may also be accessible by the corresponding customer entities2310 and/or the ERP system 2322.

FIG. 25 is a block diagram showing more details of a tax complianceinformation generation engine 2382 of FIG. 23 , according to variousembodiments of the present disclosure.

Shown is a transaction data aggregation engine 2521 that may receive thecustomer sales data 2372. For example, the transaction data aggregationengine 2521 may compile transaction data of customer entities fromcustomer sales data 2372, such as customer entities 2310 of FIG. 23 .For example, such transaction data may include data representing, foreach of the customer entities 2310, a monetary amount of sales (e.g.,revenue) associated with one or more of the tax jurisdictions 2330and/or a volume of sales transactions (e.g., number of salestransactions) associated with one or more of the tax jurisdictions 2330.Transaction data aggregation engine 2521 may receive the customer salesdata 2372 and compile such data from one or more sources, including, butnot limited to, data customer data 2329 from database 2328 and/or ERPsystem 2322 of FIG. 23 .

Shown coupled to the transaction data aggregation engine 2521 isgeographic apportionment engine 2523 that may aggregate and apportiongeographically the compiled transaction data from the transaction dataaggregation engine 2521 to produce a record of transactions apportionedto each geographic region, which may each correspond to one or moreindividual tax jurisdictions. For example, transactions of a particularcustomer entity that occurred in (e.g., are for products that wereshipped to) or are otherwise associated with geographic area 1 accordingto the rules for establishing nexus for the tax jurisdiction associatedwith geographic area 1 may be assigned, grouped or otherwise apportionedto geographic area 1 record 2525. Similarly, transactions of aparticular customer entity that are associated with geographic area 2according to the rules for establishing nexus for the tax jurisdictionassociated with geographic area 2, may be assigned, grouped or otherwiseapportioned to geographic area 2 record 2527, and so on. For example,the geographic area 1 record 2525, geographic area 2 record 2527, etc.,may comprise the record of aggregate transactions 2410 of FIG. 24 . Insome embodiments, there may be a geographic area record of transactionsin each tax jurisdiction in the U.S. (e.g., for each state of the U.S.)that has a requirement for establishing nexus for purposes of remittingtransaction tax in that jurisdiction.

Shown as receiving the geographic apportionment records (e.g.,geographic area 1 record 2525, geographic area 2 record 2527, etc.) fromthe geographic apportionment engine 2523 is the comparison engine 2529.The comparison engine 2529 may compare the geographic apportionmentrecords for one or more customer entities 2310 to updated nexus rules2519 about establishing nexus for purposes of remitting transaction taxin the plurality of tax jurisdictions, which may include statutory rulethreshold records from tax content management component 2344. Forexample, the statutory rule threshold records from tax contentmanagement component 2344 may include nexus rules 2519 regarding amonetary amount of sales that are associated with each of various taxjurisdictions and/or a volume of sales transactions that are associatedwith each of various tax jurisdictions.

Shown coupled to the comparison engine 2529 is the tax compliancedetermination engine 2531. Based on such comparison made by thecomparison engine 2529, the tax compliance determination engine 2531 maydetermine which records of the geographic apportionment records (e.g.,geographic area 1 record 2525, geographic area 2 record 2527, etc.)include transactions that meet, are within a predetermined threshold ofmeeting, and/or exceed one or more thresholds regarding sales for thecorresponding individual tax jurisdiction associated with thegeographical area. For example, based on such comparison made by thecomparison engine 2529, the tax compliance determination engine 2531 mayfind that the records of geographic area 1 record 2525 for a particularcustomer entity exceed the threshold number of transactions in theapplicable time period for the tax jurisdiction associated withgeographic area 1. The tax compliance determination engine 2531 may thendetermine there is a potential lack of tax compliance of the particularcustomer entity in the tax jurisdiction associated with geographic area1 based on this finding. The tax compliance determination engine 2531may then generate tax compliance data 2180, which, for example, may be,include, or reference notifications to individual customer entitiesindicating potential lack of tax compliance in various jurisdictions.

FIG. 26 depicts an example user interface 2600 showing examplenotifications about information regarding potential lack of taxcompliance, according to various embodiments of the present disclosure.

User interface 2600 includes a user interface screen 2602 showing anexample of information regarding potential lack of tax compliance of aparticular customer entity (e.g., customer entity 2313 of FIG. 23 ) forvarious tax jurisdictions. The user interface may include and/orrepresent tax compliance data 2180. Shown is a map 2608 of the U.S.having U.S. states highlighted in which the customer entity 2313 has apotential lack of tax compliance, for example, as determined by the taxcompliance determination engine 2531 of the tax compliance informationgeneration engine 2382. In some embodiments, the states may be colorcoded or otherwise differently highlighted or marked to indicate whethera threshold for establishing nexus for purposes of remitting transactiontax in that state is being approached or has been exceeded. For example,the user interface screen 2602 indicates that states for which thecustomer entity 2313 has exceeded a threshold of that state forestablishing nexus are colored dark gray 2604 on the map 2608. The userinterface screen 2602 indicates that states for which the customerentity 2313 is approaching a threshold of that state for establishingnexus are colored light gray on the map 2608.

In the example shown, among other states, the map 2608 indicates, bycoloring Colorado 2610 dark gray 2604, that customer 2313 has exceededthe threshold of Colorado 2610 for establishing nexus in that state.Also, the map 2608 indicates, by coloring Alabama 2612 light gray 2606,that customer 2313 is approaching the threshold of Alabama 2612 forestablishing nexus in that state. The user interface 2602, including themap 2608, may be updated dynamically, automatically and/or in real timeor near real time by the tax compliance information generation engine2382 for the applicable customer entity as sales of the customer entitychange and/or rules for establishing nexus change for variousjurisdictions. The user interface 2602, including the map 2608, may beaccessible in an account associated with the particular customer entityand/or, in some embodiments, comprise or be included in an electronicnotification regarding potential lack of tax compliance to the customerentity. For example, the user interface 2602, including the map 2608,may comprise or be included in, one or more of: an email, updates touser accounts, text messages, chat messages, web-based messages, desktopcomputer alerts, pop-up messages or alerts, mobile device messages,mobile device applications, etc. In some embodiments, a message thatincludes or refers to a representation or reproduction of the userinterface screen 2602 may be electronically initiated by the taxcompliance information generation engine 2382 to be sent by mail orcourier to an address selected by the particular customer entity.

The map 2608 may also be interactive, for example, such that the usermay click on or otherwise select one or more states and receive furtherinformation, options, actions and/or features pertaining to potentiallack of tax compliance of the customer entity for that jurisdiction. Forexample, a user of the customer entity 2313 may click on Colorado 2610and electronically receive or be presented with one or more of:information regarding rules for establishing nexus in Colorado; reasonsfor which there was a determination of potential lack of tax compliancein Colorado; which transactions of customer entity 2313 caused thedetermination of potential lack of tax compliance in Colorado; steps tobecome tax compliant in Colorado; options to select for the TAE 2342and/or the tax compliance information generation engine 2382 to performfor customer entity 2313 to become tax compliant in Colorado; options toselect for the TAE 2342 and/or the tax compliance information generationengine 2382 to initiate or perform registration with Colorado's taxingagency for collecting and/or remitting transaction taxes; options toselect for the TAE 2342 and/or the tax compliance information generationengine 2382 to initiate or perform set up of internal processes forcollecting sales tax in Colorado in accordance with the tax rules ofthat state; options to select for the TAE 2342 and/or the tax complianceinformation generation engine 2382 to initiate or perform keeping ofrecords for the collected sales tax for Colorado; options to select forthe TAE 2342 and/or the tax compliance information generation engine2382 to initiate or perform filing of reports with Colorado; options toselect for the TAE 2342 and/or the tax compliance information generationengine 2382 to initiate or perform paying or otherwise remitting oftransaction taxes to Colorado; options to select for the TAE 2342 and/orthe tax compliance information generation engine 2382 to initiate orperform requesting exemption certificates from tax exempt sellers forcustomer entity 2313 in Colorado. In various embodiments, suchoperations may be performed by the TAE 2342 and/or the tax complianceinformation generation engine 2382 for various other particularjurisdictions and, at the selection of the particular customer entity,automatically in response to a determination by the tax complianceinformation generation engine 2382 that there is a potential lack of taxcompliance in the particular jurisdiction. For example, in response tothe tax compliance information generation engine 2382 determining thatcustomer entity 2313 has exceeded the threshold of Colorado 2610 forestablishing nexus in that state, the TAE 2342 and/or the tax complianceinformation generation engine 2382 may automatically perform or takesteps to initiate performance of registration of customer entity 2313with Colorado's taxing agency for collecting and/or remittingtransaction taxes and, in some embodiments, initiate or perform payingor otherwise remitting of transactions taxes to Colorado for customerentity 2313.

FIG. 27 is a flow diagram of an example process 2700 for generatinginformation regarding potential lack of tax compliance of an entity andtransmitting a corresponding notification, according to variousembodiments of the present disclosure.

At 2702, the system 2100 updates stored rules for a certain one of aplurality of tax jurisdictions. The stored rules may be aboutestablishing nexus for purposes of remitting transaction tax in thecertain tax jurisdiction. The system 2100 may also monitor changes inrules for the plurality of tax jurisdictions and the updating the storedrules may be performed in response to the monitoring.

At 2704, the system 2100 compares stored information about goods orservices sold by an entity in the certain tax jurisdiction against theupdated stored rules for the certain tax jurisdiction. The comparing mayinclude determining whether one or more thresholds regarding goods orservices sold by the entity for establishing nexus for purposes ofremitting transaction tax in the certain tax jurisdiction are met, arewithin a predetermined threshold of being met, or are exceeded. Forexample, the comparing may include comparing the stored informationabout goods or services sold by the entity to one or more thresholdsregarding sales. The one or more thresholds regarding sales may beassociated with requirements to remit transaction taxes for the certaintax jurisdiction.

In some embodiments, the comparing may be in response to the updating ofthe stored rules. The system 2100 may detect a change in the storedinformation about goods or services sold by the entity. The comparingmay then be in response to the detected change in the stored informationabout goods or services sold by the entity. In some embodiments, thechange in the stored information about goods or services sold by theentity is a change detected in one or more of: a monetary amount ofsales of the entity that are associated with the certain taxjurisdiction and a volume of sales transactions of the entity that areassociated with the certain tax jurisdiction.

At 2706, the system 2100 generates information regarding potential lackof tax compliance of the entity for the certain tax jurisdiction basedon the comparison. The system 100 may determine there is a potentiallack of tax compliance of the entity in the certain tax jurisdiction ifthe one or more thresholds regarding sales associated with requirementsto remit transaction taxes for the tax jurisdiction are met, are withina predetermined threshold of being met, or are exceeded.

At 2708, the system transmits over a network, to a client computingdevice associated with the entity, a notification about the generationof the information. In some embodiments, the information is presentedgraphically and/or includes a map of the certain tax jurisdiction. Thetransmitting the notification about the generation of the informationmay include alerting the entity of potential lack of tax compliance byat least causing an indication of each of the plurality of taxjurisdictions for which there exists a potential lack of tax complianceof the entity to be presented on a map. The transmitting of thenotification may, in some embodiments, include aggregating thedetermined records of the one or more records of aggregate transactions.For each determined record of the aggregated determined records, thesystem 2100 may notify an entity associated with the determined recordthat there is a potential lack of tax compliance of the entity for oneor more of the corresponding individual tax jurisdictions.

FIG. 28 is a flow diagram of an example process 2800 useful ingenerating information regarding potential lack of tax compliance,according to various embodiments of the present disclosure. For example,comparing of stored information about goods or services sold by aplurality of entities against the stored rules about establishing nexusfor purposes of remitting transaction tax in the plurality of taxjurisdictions may include the process 2800.

At 2802, the system 2100 aggregates transaction data from the storedinformation about goods or services sold by the plurality of entities.

At 2804, the system apportions the transaction data geographically tocorresponding individual tax jurisdictions of the plurality of taxjurisdictions.

At 2806, the system 2100 generates one or more records of aggregatetransactions based on the apportioning. The generating one or morerecords of aggregate transactions may include determining, based on thecomparing, which records of the one or more records of aggregatetransactions meet, are within a predetermined threshold of meeting, orexceed one or more thresholds regarding sales for one or more of thecorresponding individual tax jurisdictions.

At 2808, the system 2100 compares the one or more records of aggregatetransactions to one or more thresholds regarding sales for each of thecorresponding individual tax jurisdictions based on the apportioning.The one or more thresholds may be regarding sales associated withestablishing nexus for purposes of remitting transaction tax in thecorresponding individual tax jurisdictions.

FIG. 29 is a flow diagram of an example process 2900 useful indetermining for an entity whether there is a potential lack of taxcompliance in a tax jurisdiction based on aggregated transactions,according to various embodiments of the present disclosure.

At 2902, the system 2100 receives a record of aggregated transactions ofa customer entity for a particular jurisdiction.

At 2904, the system 2100 determines whether the record of aggregatedtransactions for the jurisdiction meets, is within a predeterminedthreshold of meeting, or exceeds one or more thresholds regarding salesfor the tax jurisdiction. For example, the system 100 may total therevenue received for all the transactions in the record and/or determinea total number of transactions over applicable periods of time andcompare these totals to corresponding thresholds included in updatedrules for establishing nexus for the tax jurisdiction to determinewhether the corresponding totals meet, are within a predeterminedthreshold of meeting, or exceed the thresholds regarding sales for thetax jurisdiction.

If it is determined by the system 2100 at 2904 that the record ofaggregated transactions for the jurisdiction does not meet, is notwithin a predetermined threshold of meeting and does not exceed the oneor more thresholds regarding sales for the tax jurisdiction, then theprocess 2900 proceeds back to 2902 to receive a record of aggregatedtransactions of the particular customer entity for another jurisdiction.If it is determined at 904 that the record of aggregated transactionsfor the jurisdiction meets, is within a predetermined threshold ofmeeting, or exceeds one or more thresholds regarding sales for the taxjurisdiction, then the process 2900 proceeds to 2906.

At 2906, the system 2100 transmits a notification to the entityassociated with that there is a potential lack of tax compliance of theentity for the particular tax jurisdiction and the process proceeds to2902 to receive a record of aggregated transactions of the customerentity for another jurisdiction. This notification may be transmitted inresponse to the determination by the system 2100 at 2904 that the recordof aggregated transactions for the jurisdiction meets, is within apredetermined threshold of meeting, or exceeds one or more thresholdsregarding sales for the tax jurisdiction.

FIG. 30 is a flow diagram of an example process 3000 for notifying aplurality of entities whether there is a potential lack of taxcompliance in a plurality of jurisdictions, according to variousembodiments of the present disclosure.

At 3002, the system 2100 electronically accesses information about goodsor services sold by a particular customer entity of a plurality ofcustomer entities.

At 3004, the system 2100, electronically accesses rules for establishingnexus for a particular tax jurisdiction of a plurality of taxjurisdictions.

At 3006, the system 2100 determines whether there exists a potentiallack of transaction tax compliance of the particular entity in theparticular tax jurisdiction based on the accessed information. If it isdetermined by the system 2100 that there exists a potential lack oftransaction tax compliance of the particular entity in the particulartax jurisdiction based on the accessed information, the process 2100proceeds to 3008. If it is determined by the system 2100 that there doesnot exist a potential lack of transaction tax compliance of theparticular entity in the particular tax jurisdiction based on theaccessed information, the process 2100 proceeds to 1010.

At 3008, the system electronically notifies the entity regarding thepotential lack of tax compliance.

At 3010, the system 2100 determines whether there are additional taxjurisdictions to consider for the particular entity, such as if theentity has transactions associated with an additional tax jurisdictionthat has rules for establishing nexus for purposes of remittingtransaction tax in that additional jurisdiction. If it is determined bythe system 2100 that there are additional tax jurisdictions to considerfor the particular entity, then the process proceeds to 3004 to accessthose particular rules for that additional jurisdiction. If it isdetermined by the system 2100 that there are no additional taxjurisdictions to consider for the particular entity, then the processproceeds to 3012.

At 3012, the system 2100 determines whether there are additionalcustomer entities to consider, such as when there are additionalcustomer entities that have transactions in one or more taxjurisdictions that have rules for establishing nexus for purposes ofremitting transaction tax in that additional jurisdiction. If it isdetermined by the system 2100 that there are additional customerentities to consider, then the process proceeds to 3002 to accessinformation about goods or services sold by that additional customerentity in a particular tax jurisdiction. If it is determined by thesystem 2100 that there are no additional customer entities to consider,then the process ends at 3014.

FIG. 31 is a flow diagram of another example process 3100 for notifyinga plurality of entities whether there is a potential lack of taxcompliance, according to various embodiments of the present disclosure.

At 3102, the system 2100 electronically accesses information about goodsor services sold by a plurality of entities.

At 3104, the system 2100 determines, for each entity of the plurality ofentities, whether there exists a potential lack of transaction taxcompliance of the entity in each tax jurisdiction of a plurality of taxjurisdictions based on the accessed information.

At 3106, the system 2100, for each entity of the plurality of entitiesfor which it is determined by the computer system there exists potentiallack of tax compliance in one or more of the plurality of taxjurisdictions, electronically notifies the entity regarding thepotential lack of tax compliance.

In some embodiments, the system 2100 may also generate the informationabout goods or services sold by the plurality of entities. The systemmay perform this by, for each entity of the plurality of entities,performing per-transaction transaction tax calculations for the entityto facilitate the entity to execute sales transactions associated withone or more of the plurality of tax jurisdictions for the goods orservices. The determining whether there exists a potential lack oftransaction tax compliance may include comparing the information aboutgoods or services sold by the plurality of entities against stored rulesfor the plurality of tax jurisdictions. Such stored rules may be aboutestablishing nexus for purposes of remitting transaction tax in acertain tax jurisdiction.

The comparing of the information about goods or services sold by theplurality of entities against stored rules for the plurality of taxjurisdictions may include aggregating transaction data from theinformation about goods or services sold by the plurality of entities;apportioning the transaction data geographically to correspondingindividual tax jurisdictions of the plurality of tax jurisdictions;generating one or more records of aggregate transactions based on theapportioning; and comparing the one or more records of aggregatetransactions to one or more thresholds regarding sales for each of thecorresponding individual tax jurisdictions based on the apportioning.The one or more thresholds may be in regard to sales associated withestablishing nexus for purposes of remitting transaction tax in thecorresponding individual tax jurisdictions.

Additional details about FIG. 21 and FIG. 22 are now provided. Computer2112 further includes a video adapter 2211, which is also coupled tosystem bus 2232. Video adapter 2211 may be able to drive and/or supporta screen 2221 that is used by user 2192 together with computer 2112.

In addition to screen 2221, other peripheral input/output (I/O) devicesthat may be used together with computer 2112 include a keyboard 2222, amouse 2223, a media tray 2224 and a printer 2225. Media tray 2224 mayinclude storage devices such as CD-ROM drives, multi-media interfaces,and so on. Computer 2212 moreover includes an I/O interface 2228connected to these peripheral I/O devices as shown, for the purpose ofcommunicating with them. In this example these connections are direct.Alternately, one or more of these connections may take place viauniversal serial bus (USB) ports 2229 of computer 2112, to which I/Ointerface 2228 is also connected.

Computer 2112 moreover includes a bus bridge 2216 coupled to system bus2232, and an input/output (I/O) bus 2236. I/O bus 2236 is coupled to busbridge 2216 and to I/O interface 2228.

Computer 2112 also includes various memory components. A non-volatilememory component is a hard drive 2244. Computer 2112 further includes ahard drive interface 2242 that is coupled to hard drive 2244 and systembus 2232.

Additional memory components are in a system memory 2248, which is alsocoupled to system bus 2232. System memory includes volatile memoryincluding, but not limited to, cache memory, registers and buffers. Inembodiments, data from hard drive 2244 populates registers of thevolatile memory of system memory 2248.

Sample system memory 2248 has a software architecture that uses a stackof layers, with each layer providing a particular functionality. In thisexample the layers include—starting from the bottom—an operating system(OS) 2250, libraries 2260, frameworks/middleware 2270 and applicationprograms 2280. Other software architectures may include less, more ordifferent layers. For example, a presentation layer may also beincluded. For another example, some mobile or special purpose operatingsystems may not provide a frameworks/middleware 2270.

OS 2250 may manage hardware resources and provide common services.Libraries 2260 provide a common infrastructure that is used byapplication programs 2280 and/or other components and/or layers.Libraries 2260 provide functionality that allows other softwarecomponents to perform tasks in a more easy fashion than to interfacedirectly with the specific underlying functionality of OS 2250.Libraries 2260 may include system libraries 2261, such as a C standardlibrary. System libraries 2261 may provide functions such as memoryallocation functions, string manipulation functions, mathematicalfunctions, and the like.

In addition, libraries 2260 may include API libraries 2262 and otherlibraries 2263. API libraries 2262 may include media libraries, such aslibraries to support presentation and manipulation of various mediaformats such as MPREG4, H.264, MP3, AAC, AMR, JPG, and PNG. APIlibraries 2262 may also include graphics libraries, for instance anOpenGL framework that may be used to render 2D and 3D in a graphiccontent on screen 2221. API libraries 2262 may further include databaselibraries, for instance SQLite, which may support various relationaldatabase functions. API libraries 2262 may additionally include weblibraries, for instance WebKit, which may support web browsingfunctionality.

Frameworks/middleware 2270 may provide a higher-level commoninfrastructure that may be used by application programs 2280 and/orother software components/modules. For example, frameworks/middleware2270 may provide various graphic user interface (GUI) functions,high-level resource management, high-level location services, and soforth. Frameworks/middleware 2270 may provide a broad spectrum of otherAPIs that may be used by application programs 2280 and/or other softwarecomponents/modules, some of which may be specific to OS 2250 or to aplatform.

Application programs 2280 are also known more simply as applications andapps. One such app is a browser 2281. Browser 2281 is an example of arenderer, which includes program modules and instructions that enablecomputer 2112, to exchange network messages with network 2194 usinghypertext transfer protocol (HTTP) messaging.

Other such application programs 2280 may include a contacts application,a book reader application, a location application, a media application,a messaging application, and so on. Application programs 2280 may bedeveloped using the ANDROID™ or IOS™ software development kit (SDK) byan entity other than the vendor of the particular platform, and may bemobile software running on a mobile operating system such as IOS™,ANDROID™ WINDOWS® Phone, or other mobile operating systems. Applicationprograms 2280 may use built-in functions of OS 2250, libraries 2260, andframeworks/middleware 2270 to create user interfaces for user 2192 tointeract with.

The hardware elements depicted in computer 2112 are not intended to beexhaustive. Rather, they are representative, for highlighting essentialcomponents that can be used with embodiments.

Instructions for performing any of the methods or functions describedherein may be stored, completely or partially, within the memorycomponents of server computer 2141, computer 2112, etc. These memorycomponents include the indicated memory components, plus cache memorywithin the processors such as processor 2214. Accordingly, these memorycomponents are examples of machine-readable media.

In this context, “machine-readable medium” or “computer-readable medium”refers to a component, device or other tangible media able to storeinstructions and data temporarily or permanently and may include, but isnot limited to, a portable computer diskette, a thumb drive, a harddisk, random-access memory (RAM), read-only memory (ROM), buffer memory,flash memory, optical media, magnetic media, cache memory, an ErasableProgrammable Read-Only Memory (EPROM), an optical fiber, a portablecompact disc read-only memory (CD-ROM), an optical storage device, amagnetic storage device, or any suitable combination of the foregoing.

The term “machine-readable medium” or “computer-readable medium” shouldbe taken to include a single medium or multiple media (e.g., acentralized or distributed database, or associated caches and servers)able to store instructions that a machine such as a processor can store,erase, or read. The term “machine-readable medium” or “computer-readablemedium” shall also be taken to include any medium, or combination ofmultiple media, that is capable of storing instructions (e.g., code) forexecution by a machine, such that the instructions, when executed by oneor more processors of the machine, cause the machine to perform any oneor more of the methods described herein. Accordingly, instructionstransform a general, non-programmed machine into a particular machineprogrammed to carry out the described and illustrated functions in themanner described.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Processor 2214, as well as the processor of server computer 2141, is aphysical circuit that manipulates physical quantities representing datavalues. The manipulation can be according to control signals, which canbe known as commands, op codes, machine code, etc. The manipulation canproduce corresponding output signals that are applied to operate amachine. As such, a processor may, for example, be a Central ProcessingUnit (CPU), a Reduced Instruction Set Computing (RISC) processor, aComplex Instruction Set Computing (CISC) processor, a GraphicsProcessing Unit (GPU), a Digital Signal Processor (DSP), aField-Programmable Gate Array (FPGA), an Application Specific IntegratedCircuit (ASIC), any combination of these, and so on. A processor mayfurther be a multi-core processor having two or more independentprocessors that execute instructions. Such independent processors aresometimes called “cores”.

A hardware component such as a processor may also include programmablelogic or circuitry that is temporarily configured by software to performcertain operations. For example, a hardware component may includesoftware executed by a general-purpose processor or other programmableprocessor. Once configured by such software, hardware components becomespecific machines, or specific components of a machine, uniquelytailored to perform the configured functions and are no longergeneral-purpose processors. It will be appreciated that the decision toimplement a hardware component mechanically, in dedicated andpermanently configured circuitry, or in temporarily configured circuitry(e.g., configured by software) may be driven by cost and timeconsiderations.

As used herein, a “component” may refer to a device, physical entity orlogic having boundaries defined by function or subroutine calls, branchpoints, application programming interfaces (APIs), or other technologiesthat provide for the partitioning or modularization of particularprocessing or control functions. Components may be combined via theirinterfaces with other components to carry out a machine process. Acomponent may be a packaged functional hardware unit designed for usewith other components and a part of a program that usually performs aparticular function of related functions. Components may constituteeither software components (e.g., code embodied on a machine-readablemedium) or hardware components.

Where a phrase similar to “at least one of A, B, or C,” “at least one ofA, B, and C,” “one or more A, B, or C,” or “one or more of A, B, and C”is used, it is intended that the phrase be interpreted to mean that Aalone may be present in an embodiment, B alone may be present in anembodiment, C alone may be present in an embodiment, or that anycombination of the elements A, B and C may be present in a singleembodiment; for example, A and B, A and C, B and C, or A and B and C.

As used herein, the term “or” may be construed in either an inclusive orexclusive sense. Moreover, plural instances may be provided forresources, operations, or structures described herein as a singleinstance. Additionally, particular operations are illustrated in acontext of specific illustrative configurations. Other allocations offunctionality are envisioned and may fall within a scope of variousembodiments of the present disclosure. In general, structures andfunctionality presented as separate resources in the exampleconfigurations may be implemented as a combined structure or resource.Similarly, structures and functionality presented as a single resourcemay be implemented as separate resources. These and other variations,modifications, additions, and improvements fall within a scope ofembodiments of the present disclosure as represented by the appendedclaims. The specification and drawings are, accordingly, to be regardedin an illustrative rather than a restrictive sense.

The various embodiments described above can be combined to providefurther embodiments. These and other changes can be made to theembodiments in light of the above-detailed description. In general, inthe following claims, the terms used should not be construed to limitthe claims to the specific embodiments disclosed in the specificationand the claims, but should be construed to include all possibleembodiments along with the full scope of equivalents to which suchclaims are entitled. Accordingly, the claims are not limited by thedisclosure.

1. A computer system of a client entity that is configured to cooperatewith an online service platform (OSP), the computer system including atleast: one or more processors, a local output device; and anon-transitory computer-readable storage medium having stored thereoninstructions which, when executed by the one or more processors, resultin operations including at least: storing locally on the storage mediuma client computing facility (CCF) that includes digital rules;receiving, from the OSP across a network, a coarse values file (CVF)that includes values; generating a dataset that represents arelationship instance of the client entity with another entity;producing, by the digital rules of the CCF and the values of the CVF, alocal estimate of a resource for the dataset; and outputting the localestimate to the local output device in conjunction with the dataset. 2.The system of claim 1, in which the operations further include:receiving, from the OSP across the network, an updated CVF that includesupdated values; storing locally on the storage medium the updated CVF toreplace the CVF; producing, by the digital rules of the CCF and theupdated values of the updated CVF, an additional local estimate of aresource for the dataset; and outputting the additional local estimateto the local output device in conjunction with the dataset.
 3. Thesystem of claim 1, in which the operations further include: determiningwhether producing the local estimate of the resource for the dataset hasbeen enabled by the CCF, in which the producing of the local estimate isperformed if it is determined producing the local estimate of theresource for the dataset has been enabled; and if it is determinedproducing the local estimate of the resource for the dataset has notbeen enabled, then, instead of producing the local estimate: producing,via one or more computer network calls to an online service platform(OSP) system, a more accurate estimate of the resource that is moreaccurate than the local estimate based on the dataset and digital rulesstored remotely at the OSP system; receiving the more accurate estimatefrom the OSP system; and outputting the more accurate estimate to thelocal output device in conjunction with the dataset.
 4. The system ofclaim 3, in which the operations further include: presenting a selectionof options via a graphical user interface (GUI), in which the optionsinclude, for the dataset, one or more of: producing the local estimateand receiving the more accurate estimate; and receiving a selection ofthe options, in which the producing the local estimate and the producingthe more accurate estimate is based on the selection.
 5. The system ofclaim 3, in which the CVF values include values for a plurality ofparameters that are used to produce the local estimate and the pluralityof parameters that are used to produce the local estimate include fewerparameters than used by the OSP to produce the more accurate estimate.6. The system of claim 1, in which the operations further include: afterproducing the local estimate, transmitting a follow-up computer networkcall to the OSP system to produce a more accurate estimate of theresource that is more accurate than the local estimate based on thedataset and digital rules stored remotely at the OSP system; and inresponse to the transmitting the follow-up computer network call to theOSP system, receiving the more accurate estimate from the OSP system. 7.The system of claim 6, in which the local estimate is transmitted to theOSP for reconciliation with the more accurate estimate to finddiscrepancies between the local estimate and the more accurate estimate.8. The system of claim 6, in which the operations further include:reconciling the local estimate with the more accurate estimate to finddiscrepancies between the local estimate and the more accurate estimate.9. The system of claim 6, in which the operations further include:computing differences between the local estimate and the more accurateestimate; and recording the differences between the local estimate andthe more accurate estimate.
 10. The system of claim 9, in which theoperations further include: electronically issuing one or more resourcerefunds based on the differences between the local estimate and the moreaccurate estimate.
 11. The system of claim 6, in which the operationsfurther include: receiving input indicating scheduling of the follow-upcomputer network call to the OSP system; and performing the follow-upcomputer network call to the OSP system according to the inputindicating the scheduling.
 12. The system of claim 11, in whichreceiving input indicating scheduling of the follow-up computer networkcall to the OSP indicates that follow-up computer network call to theOSP is to occur based on internet response times exceeding one or morethresholds.
 13. The system of claim 1, in which the operations furtherinclude: determining whether selectable conditions are met in which toproduce a more accurate estimate of the resource via one or morecomputer network calls to an online service platform (OSP) system; andin response to determining that the selectable conditions are met,producing, via one or more computer network calls to the OSP system, themore accurate estimate based on the dataset.
 14. The system of claim 1,in which the operations further include: before receiving the CVF,receiving, from the OSP system, data comprising the CCF.
 15. The systemof claim 14, in which the CCF is received from the OSP system as part ofa software development kit (SDK).
 16. A computer-implemented methodexecuted on a computing device comprising at least one physicalprocessor, the method comprising: compiling transaction data receivedfrom across a computer network; aggregating the transaction data thatwas received across the computer network; apportioning the transactiondata geographically to create a record of aggregate transactions;comparing the record of aggregate transactions to thresholds storedwithin a set of rule threshold records; determining which entities have,according to the aggregate of records, transactions, in aggregate, thatmeet, exceed, or are approaching a threshold for one or morecorresponding geographic locations; transmitting, across the computernetwork, corresponding notifications to each of the entities which,according to the aggregate of records, have transactions, in aggregate,that meet, exceed, or are approaching the threshold for the one or moreof the corresponding geographic locations; in which: apportioning thetransaction data that was received across the computer network comprisesgrouping the transaction data into separate groups; each respective oneof the separate groups indicates a different combination of (i) anentity that engaged in transactions for that respective group and (ii) arespective geographic location with which the transactions for thatrespective group are associated; and each one of the correspondingnotifications indicates to each respective entity that the respectiveentity, according to the aggregate of records, has transactions, inaggregate, that meet, exceed, or are approaching the threshold for arespective geographic location in the geographic locations.
 17. Thecomputer-implemented method of claim 16, wherein each geographiclocation comprises a separate jurisdiction.
 18. The computer-implementedmethod of claim 16, wherein each geographic location comprises a state.19. The computer-implemented method of claim 16, further comprisingfirst checking the rule threshold records and then comparing theseagainst the record of aggregate transactions.
 20. Thecomputer-implemented method of claim 16, wherein the correspondingnotifications indicate to each respective entity that the respectiveentity is potentially not complying with a corresponding jurisdiction.